Why I'm Making Python 2.8 - <AUTHOR> https://www.naftaliharris.com/blog/why-making-python-2.8/ <comment><USER2> > _And the majority of Python code written does not run under any of the 3.x > interpreters. This makes it harder for its users to be productive._

What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you.

> _Unlike 2.7 code, Python 2.8 wouldn 't be able to guarantee exact 3.x > compatibility, since there are some python scripts that will run under both > Python 2.7 and Python 3.x but produce different output, and Python 2.8 > chooses the 2.7 behavior in these cases._

What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x. As for the latter, please explain how that will alleviate anything on the following point, since behaviour at runtime will be subtly different:

> _adding these remaining Python 3 features would greatly simplify running > code targeting Python 3, and allow people to use Python 2.8 to run a mix of > Python 2 and 3 code._

I don't know what recourse the PSF has but maybe they should even go all in and defend the "Python" name so as to prevent confusion and stop a potential community fracture. Just call it anything else but "Python 2.8" is not Python.

<comment><USER3> I currently work for a client who has decided to shift away from PHP and towards Python. They had a monolithic PHP app with perhaps 250,000 lines of code. Now we are developing a series of Python apps in the microservices style. We've decided to develop everything as Python 2.7. We are not looking at Python 3.x. There are a few reasons. Some libraries that we want are in Python 2.7. And Amazon only supports 2.7. And we are not wild about Python 3.x's attempt to imitate a classical object oriented style.

We would look very closely at a Python 2.8, if it existed.

<comment><USER4> If I was your client I'd be pissed that you decided to rewrite my code into a legacy version of Python. Make no mistake: Python 3 is the future of Python. There will be no version 2.8 and there is no going back to 2.7.

Also, I don't know what you mean by "Amazon only supports 2.7" because boto (the main client for Python) has supported Python 3 for 2 years now. Perhaps you mean Lambda?

<comment><USER5> +1. Also it's easy to write code that supports both, so if you really need python 2 support right now (surely AWS Lambda python 3 is coming soon, you can already use it unofficially) that's a much better option than being entrenched in python 2 (mainly the string handling is the issue for buggy code that'll run in 2 but not 3).

</comment></comment></comment></comment><comment><USER6> As others have said, maybe this project fixes some actual problems and backports some features from 3, but this isn't "Python". Beyond the fact that Python is a trademark of the Python Software Foundation, Python is more than the language, it's the community and the tools (as with every programming language). So while there are some vocal people that really dislike Python 3 (either in part or wholly), my understanding is that with the planned phase out of Python 2 and Python 2 only receiving bug fixes at this point, much of the industry is transitioning to Python 3 (either currently doing so or planning to) and so it seems relatively fruitless to attempt to build upon Python 2. I personally think the effort put into this would be much better spent making tooling around Python 2 to 3 transformations.

I also think it's pretty irresponsible of the author to call this Python 2.8, because it may cause confusion to developers unfamiliar with the history and come from a tutorial that is still in Python 2 (it does show up on the first page of Google for me). It's also especially irresponsible and hubristic to attempt to make a language that is seemingly compatible with both Python 2 and 3, because 1) I trust that if it was possible Guido and the other developers would have made it, and 2) it can cause significant confusion when code doesn't work when it hits an edge case, and then the whole tooling around it can't be guaranteed to work. The last thing I'd want in my programming language is unaccounted for ambiguity.

<comment><USER7> I don't know about that. It forked a Python compiler, and is fully interoperable with 100% of Python 2 code, and much of Python 3 code. It's even compatible with Python C extensions.

Why isn't it a valid Python compiler?

To me, the whole morass about trying to end-of-life Python 2 is a bit silly. People have gotten emotional about the situation.

On one side, people like Zed Shaw are calling the Python maintainers 'evil' and claiming conspiracy.

On the other side, people are calling companies using Python 2, 'lazy' and claim they're a threat to the ecosystem.

Yet elsewhere, C is still being written in all of its various year-specific formats, and people end up using 'old' versions simply because they join pre- existing projects or need to totally interface with something that's written in an 'old' version.

Python is an extablished language, it's likely that 10 years from now there will still be Python 2 codebases going strong.

<comment><USER6> There are some fair points, but unlike C or other languages that have "old" versions, most of the newer versions are compatible with this old code (as in, if you have some C89 code, you can compile it in the newest C compiler. Same with Fortran). This isn't the case with Python 3 (there are breaking changes), and I think it's fair that the Python core developers who, besides Guido, probably work on this for free decide that it's time to end the older, non- compatible version and give ample time for developers to move their codebases, adding bug fixes and security fixes in the mean time until EOL is reached.

My biggest gripe with this project besides calling this Python is that it's seemingly ambiguous with its code compatibility. I don't mind ambiguity in programming languages, but generally the ambiguous cases are explicitly defined with cases to explain them, and I don't see anything of that nature here, only something that vaguely says that if there's something that works in both the Python 2.7 way will be the default. Without defining those it's hard to know what could happen in an edge case and this could introduce specific bugs that don't present themselves immediately but introduce data weirdness because the cases where something may be ambiguous wasn't defined.

In any case, I think that if a company has a really big, maintained code base in Python 2, it's their fault for supporting an older, in-2020-unsupported version of a programming language and the money/developer time spent supporting the codebase could be spent transitioning it to Python 3. I can understand a little more with an open source project because time is more precious and generally that time is donated, but even then most bigger projects (Numpy, Scipy, Django) have moved to Python 2/3 compatibility so unless the project is gargantuan there's no real excuse besides the project is not maintained.

<comment><USER8> They transitioned with a lot of community support and did sooner the course of years. It wasn't easy to support 2/3 out of the box. For a normal company, staying on 2 is like keeping technical debt and we all know how companies loathe to allow weeks for major refactoring when the gains aren't immediately visible. My company switched to using puppy and eschewing c extensions before we supported python 3.

</comment></comment></comment></comment><comment> yoz-y I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.

<comment><USER9> > _Please, do not put obsolete software on life support._

Regarding adoption, it's 3.0 that's obsolete, and 2.7 that's vibrant. Even for new code (they conveniently only count totally greenfield projects, but most new code is written in fact to work with established 2.x codebases under Python 2, not as a totally greenfield project).

<comment><USER10> You keep saying things like this but numbers don't bear that out. Since we switch to Python 3.5 for new code, I can barely tolerate working in 2.7 now. It went from feeling "vibrant" to feeling "OMG this is legacy" in about a week. I would never voluntarily go back.

<comment><USER9> > _You keep saying things like this but numbers don 't bear that out._

What numbers? All the numbers I've seen -- official numbers from PyPY etc) tell otherwise.

<comment><USER11> [https://twitter.com/vlasovskikh/status/801720613312364544](https://twitter.com/vlasovskikh/status/801720613312364544)

<comment><USER12> There is a clear selection bias here, which is revealed in the first response (unless that was what you're pointing people towards). IDEs are a lot more common on Windows, which has the best adoption rate. The data from the two sources in that comment point towards a large majority of users still using 2.7, which agrees with my experience (which is in the scientific community). The number one reason being that there is no incentive. There is a lot of that attitude is common, "if it isn't broken, don't fix it". At this point we need to recognize that python2.7 isn't going to die anytime soon, unless there is a drastic change.

<comment><USER11> While the claim of selection bias in JetBrains' survey may be argued, it is still a valid data source, which is what the gp was asking for.

Also, your anecdotal data is arguably biased as well.

My take is that many sources, including the ones linked to in the tweet's replies point to solid growth in Python 3 adoption. Python3 might not have overtaken Python 2 overall, but it's very far from being "dead".

<comment><USER9> > _While the claim of selection bias in JetBrains ' survey may be argued, it > is still a valid data source, which is what the gp was asking for._

No, I asked for a representative data source (representative was implied: a biased data source is as good as no data source at all).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> The worst thing about open source is that people can do stupid stuff with your software.

If you're going to create this abomination, at least do us all a favour and DON'T call it Python. Call it Retardython or something. I don't want to imagine people coming into the official support channels and claiming they are using "Python 2.8", then other people lecturing them about what that software really is, etc. Sounds like a horrible waste of time. (Source: I spend many hours a week helping fellow Python users.)

<comment><USER14> Python is trademarked by the Python Software foundation. IANAL but pretty sure that means he doesn't get to call it Python 2.8

<comment><USER15> Only if the PSF does something about it...

<comment><USER16> If they don't protect their trademark they open themselves up to what is essentially loss of the trademark in the US.

They could license it to Python 2.8 for free if they want to, though it seems unlikely.

</comment></comment></comment></comment><comment><USER17> Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.

<comment><USER18> Companies with Python code are probably better off keeping their working, tested code than switching to an incompatible interpreter and set of libraries which among other things will print "b'Hello',b'World'" into their mission critical CSV files.

Yes, the built in csv module really does that in Python 3.

<comment><USER19> _Yes, the built in csv module really does that in Python 3._

If you pass it bytes, yes, it does. If you pass it strings, no, it doesn't.

If what you pass to the built-in CSV writer is not a string, the CSV writer will call str() to get a string representation it can write out. The string representation of a bytes object includes the 'b' prefix.

Meanwhile, you discovered your bug: you were treating bytes as text, which is likely to blow up on you sooner or later, and thanks to how Python now handles text, it blew up on you _immediately_ as a way to remind you _not to treat bytes as text_.

What you probably think you want is for the CSV writer to realize it got a bytes object and, instead of calling str(), call its decode() method to get text it can write. But that is once again a dangerous operation, and sort of the whole point of Python 3's text changes is it won't let you get away with that stuff anymore.

<comment><USER20> I had this problem.

It doesn't "blow up". If it blew up and retired, I would have seen the problem. The problem, like several python 2/3 incompatibilities, is that Python 3 merrily did something different, without telling anyone, until eventually we track down what has changed. I spent quite a while on this very bug myself, and it, along with others, persuaded me to switch to a different language (serious I know, but I was just getting annoyed with python's general loose dynamic nature, in combination with the python 2/3 changes.)

<comment><USER16> It's unreasonable to say "merrily did something different, without telling anyone" when fixing the string implementation was a significant reason for creating backwards-incompatible Python3 in the first place.

It's not a bug, it's a fix for an architectural error in Python 2, and it was quite well announced at the time: [https://docs.python.org/3.0/whatsnew/3.0.html](https://docs.python.org/3.0/whatsnew/3.0.html)

<comment><USER21> Fixing the string mess in Py2 was a good thing.

But the fact that the same code now silently does the _always wrong_ thing in Py3 wrt CSV is clearly a bug.

Actually, the design defect here is calling str() on everything, and assuming that the output is sensible for CSV. It may be a decent rule of thumb, but it _clearly_ does not apply to bytes. Given the likelihood that someone might mistakenly use bytes as a string (for example, because they're porting a legacy Py2 codebase), this should be a hard error, immediately reported as such, and not just a silent behavior change.

<comment><USER19> Except if you make an exception for bytes, what about other types that might get passed into a CSV writer, whose __str__ is something "wrong" for CSV purposes? Do they also get auto-detected? Do we add a new __csv__() method just for when outputting to CSV (since it might not be "wrong" for other output formats)? Or do we ditch str()-ifying altogether, but then add back in a bunch of special cases for numeric types and other things where str() is "the right thing"?

Or do we say "CSV outputs strings, whatever is the string representation of what you passed in is what gets written out", and trust people to figure out when they're working with something that has a "wrong" string representation for their use case?

Because remember: the whole underlying cause of this was treating a dangerously non-string value as a string. Those bytes objects should have been decoded to strings long before reaching the CSV writer. Python 3 does raise more and louder exceptions when you pass bytes to things that expect strings, but the CSV writer isn't a thing that expects strings; it expects things that have a string representation, and several common use cases get much more difficult if you change that to force every user to explicitly do throwaway casts to string in the name of protecting people who keep insisting on writing dangerous "I'll treat bytes as string until it breaks, and then complain that the language did the wrong thing, not me" code.

<comment><USER21> `bytes` is plainly special case for historical reasons here - it's something that is not a string, but that so many people _assume_ to be a string.

So yeah, I would be fine with making an exception for it (and providing some kind of option to disable that exception, for that incredibly rare case where someone really does need b"foo" in their CSV output).

And then in 5 years, flip the default of that switch, and deprecate it. In another 5, remove it entirely.

Also, note that raising an error in this case is not placating the people who insist on using bytes as strings. Quite the opposite - it very loudly and unambiguously tells them that they're wrong, and how exactly they're wrong.

<comment><USER19> The entire problem, though, is people assuming bytes and strings are interchangeable. Anything which allows that assumption to go unquestioned, or without program-wrecking consequences, leads right back to where we were. And the "phase it out" model doesn't work; you proposed a ten-year phase-out, but in ten years people are just going to say "we never updated our code, we're not ready, keep it this way another ten years and we'll think about fixing our code". The only thing that works is actively breaking people's programs when they try to intermix bytes and strings.

<comment><USER21> > The only thing that works is actively breaking people's programs when they > try to intermix bytes and strings.

Um, this is _exactly_ what I proposed above!

"this should be a hard error, immediately reported as such, and not just a silent behavior change."

What I'm asking for is that csv writer raises an exception if it sees bytes anywhere by default. The problem is that right now, it doesn't! It just gives you "incorrect" output, that might go undetected for a long time.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> People don't seem to be considering the possibility that a stagnant python 2.7 may actually be a reason to like that version of the language. I must admit it is nice to not have those oh-so-keen python developers messing with my favorite language.

However, I recently had a gig working in py3. Apart from screwing up every single print statement for a long time, it was entirely drama-free, and actually pretty great. There really is a difference between living and dead languages I think. 2.7 is the latin of python.

<comment><USER23> why can't print be both a function and a statement...

<comment><USER24> The print statement has a lot of special magic like '>>' and trailing commas that uglifies the parser.

<comment><USER23> I don't get this. There's a tiny fraction of Python users who care about the complexity of the language parser. But many hate the print-tax.

</comment></comment></comment></comment><comment><USER25> Author here. Imagine my surprise when I got back from a day of sightseeing (I'm on vacation in Spain) and saw that this had blown up. I had intended to "release" this project after New Years, after I'd gotten back and a week or two after 3.6 is released [1], and didn't expect this to get picked up since the project has been on Github for over a year (although inactive for much of that time) and since my blog usually doesn't get much traffic.

A lot of people here have strong opinions about the name "Python 2.8". I don't mind changing it, and intend to do so, ([https://github.com/naftaliharris/python2.8/issues/47](https://github.com/naftaliharris/python2.8/issues/47)). I picked it initially since when talking with friends about this project it conveyed pretty darn immediately what the project is and does. I'd be very keen to hear people's suggestions for alternate names!

For those of you with 2.7 codebases or projects, I'd be extremely interested in hearing about whether you were able to get this interpreter to run your code. Personally, the biggest challenges I've had so far are with dependencies that check for `sys.version_info[:2] == (2, 7)` as opposed to something like `sys.version_info[0] < 3`. But I'd be very interested in other people's experiences, particularly with larger codebases.

[1] A minor and somewhat pedantic point: The interpreter I've been working on includes PEP 515 (underscores in numeric literals), which is new in 3.6. I didn't think it was right for me to "take credit" for this new feature before it was even out in Python 3.6. Obviously, the real credit for this feature existing (in 3.6 or in any interpreter) goes to the CPython core devs, and especially Georg Brandl.

<comment><USER26> Regardless of the detractors, I think this is brilliant work. All of the negativity around your project is over politics or subjective opinions based off of individual experience where they are lucky enough to work in environments on the bleeding edge.

Keep up the good work, this could help a lot of people!

</comment></comment><comment><USER27> Reading a thread from the last time something like that was proposed (although the only change in that proposal was that 2.8 would, on Windows, use the C runtime from a more recent MSVC compiler), I found a relevant argument ([https://mail.python.org/pipermail/python- dev/2013-November/1...](https://mail.python.org/pipermail/python- dev/2013-November/130485.html)) against this "Python 2.8" idea:

What if more than one person did that? (paraphrasing Raymond Chen's "What if two programs did this?")

There can be only one official Python 2.8, but since it will never exist (see PEP 404), there can be many unofficial mutually incompatible "Python" 2.8 implementations. Therefore, calling it "Python 2.8" is a bad idea.

</comment><comment><USER28> I see many people vigorously defending Py3 but I wonder how many of these have a paying-the-bills kind of job. Where you would look at the cost of porting a large project to Py3 and get an answer like half a million USD (easily). Do you go "of course we do that, that money is easily recouped with the added programmer productivity of Py3"? No chance.

So the question is do you want to basically light that money on fire, or just keep your perfectly fine Py2.7 code running and maintained another few years.

More discussions of the monetary value of programming languages please. What is "correct" or "right" isn't all that interesting to many, for good reasons.

Kudos to this project and hope it can set us on a saner migration path to Py3. (Should totally change the name though.)

<comment><USER29> You can keep your py2.x code running, absolutely; but you cannot expect other people _working for free_ to help you pay your bills.

Honestly, the level of self-entitlement through all 2vs3 threads is staggering.

<comment><USER28> I don't want the CPython core devs to do anything different and are not angry with them at all. It is their pet and they can do what they want. I fully agree with what you say in that sense.

But I do mind people saying in these discussions "you should all move to Py3 now or you are stupid/evil".

No. There are legitimate reasons for staying with Py2.7 and embracing it.

So I hope "Python 2.8" gets a cool name, perhaps even some funding from a company who wants to keep their Py2.7 code alive and invigorated, and the community part as friends.

Is that self-entitlement in any sense?

All I want is for people who I think have a huge blind spot to stop calling me ignorant for decisons I make about MY code. I totally don't expect core CPython devs help me out though.

<comment><USER29> _> I don't want the CPython core devs to do anything different_

It's not just CPython, it's the Python specification of which CPython is the reference implementation. The specification couldn't move forward in significant ways without making some of the changes that came with Python 3.

 _> All I want is for people who I think have a huge blind spot to stop calling me ignorant_

The level of vitriol in 2vs3 threads has been way too high _from the start_ , because people always hate change. You are obviously free to do what you want, you always were. Don't mind the haters, but please don't be one either.

<comment><USER28> Thanks for that, well said.

</comment></comment></comment></comment></comment><comment><USER30> > I've been working on Python 2.8 (not an official Python release)

It is very dishonest to call it Python 2.8 then.

<comment><USER31> I suggest Monty 2.8

</comment></comment><comment><USER32> It's too bad the python 3.x fans can't see this as feedback about how difficult it for users of 2.x to upgrade to the latest and greatest. Many 2.x folks have sprawling code bases and complex operational needs. The 3.x advocates seems to consistently ignore that.

Shoot the 2.8 messenger all you want for choosing to call it Python 2.8, but don't dismiss the issue that drives thoughtful people to get value out of this strategy.

<comment><USER33> The python maintainers and the 3.x fans do see this, and know this, and decided to do it. They knew there would be a cost in community, and decided it was worth it. They haven't been oblivious, and they've made several large concessions in 3.4 and 3.5 to increase the ease of migrating. Stop denigrating them.

</comment></comment><comment><USER22> Christian Tismer tried this a couple of years ago [1].

I guess the intention was a bit different: he wanted to have stackless features in python. It's not clear to me the reason he decided to back down, whether because of licensing issues or just because the other python developers didn't like it.

[1] [http://www.stackless.com/pipermail/stackless/2014-January/00...](http://www.stackless.com/pipermail/stackless/2014-January/006043.html)

</comment><comment><USER34> What another load of crap. Call it something else but this isn't Python. I'd never use this because it's not official. Who knows if or how long it'd be supported for or if any backdoors would/could be introduced.

I've scheduled time this year for my teams project to update to Python 3. It's expensive in the short term but in the long term we get continued support and new features which is a huge win.

<comment><USER35> Do you trust PyPy? It's not official either.

</comment></comment><comment><USER36> I can't fault a single thing in his justification. This should have been the approach to modernising python all along.

<comment><USER37> This approach could not have worked for modernizing python. The whole point of the Python 3 thing was to be able to remove warts in the language that could not have been fixed without breaking backwards compatibility. One core part of this is unicode support -- Python had a horrible story for international text before this.

The fact that there are some parts of "modern" Python which could have been implemented in Python 2.7 backwards-compatibly is irrelevant.

Python 3 is not the language designers worrying about minor subjective issues in python like the print keyword or the design of iterators and deciding that they want to change it all. It is the language designers worrying about major issues like international text, realizing that they regrettably will have to break backwards compatibility to fix those, and then just taking the opportunity to revamp things like printing and iteration since they're breaking backcompat in some pretty major ways anyway.

<comment><USER38> Python 3 fixes no fundamental issues with python 2 and introduced far more warts than it removed. GIL is still there, crummy runtime is still there and unicode is now an even greater mess. I really wonder how many people who bang on about unicode actually have a good grasp of unicode and text processing because python3's unicode design is obviously terrible. I can now access or count code points in O(1) (neither of which is in any way useful) at the cost of tremendously increasing space and time overhead for any basic text operation on non ascii text and having some bizarre hacks to deal with the fact that pretending that stdin and stdout and sys.argv are always text.

<comment><USER39> It most certainly fixes support for Unicode on Windows in terms of filesystems paths, OS function boundaries and the console. Some of these fixes have even taken until 3.6 to get implemented.

As someone who writes cross-platform code, Python 3 was a breath of fresh air after fumbling around in the dark with Python 2.

<comment><USER38> I can definitely believe that – but windows has basically lost[1] and a much worse text model to boot. Like Java and unlike python 3, they at least have the excellent excuse that this was not obvious at the time. And under unix the impedance mismatch has definitely increased. Not a good trade.

[1] I wouldn't count them out, but they're definitely on the back foot as bash inclusion shows.

</comment></comment></comment></comment></comment><comment><USER40> So when you see a project written in Python 2.8, you'll know that it contains lots of legacy code under active development by developers who are gung-ho about fancy language features, but that this team hasn't had the time/resources/gumption to do a code overhaul anytime in the past _six years_.

And also that you yourself, and any users of your own project, will need to run it with this guy's own homebrewed version of Python in order to know it will behave correctly.

Useful?

</comment><comment><USER41> I don't think this is a good idea simply because it reduces the need to upgrade your library from 2.x to 3. It's a clear cut and a good chance to weed out unmaintained libraries

<comment><USER42> Or possibly it makes it easier to have code that works on both. Although that requires this to catch on enough that 2.7 compatibility isn't required.

<comment><USER41> That would mean someone develops a library that uses features of Python 3, but needs some horrible hacking to port those features to Python 2. Thanks, but no - please make a cut and decide or split it in two separate packages.

<comment><USER43> > That would mean someone develops a library that uses features of Python 3, > but needs some horrible hacking to port those features to Python 2.

The "horrible hacking" already exists bundled into libraries and tools like Six and Future.

> split it in two seperate packages.

That was tried, and failed every time. Because now you end up with two diverging and hard to reconcile code bases. A single-source cross-version library, while not trivial (and not allowing the user of more advanced P3 features) works way better.

<comment><USER44> > The "horrible hacking" already exists bundled into libraries and tools like > Six and Future.

Only for the simplest cases. How is Six going to help you write a regex that matches emoji, for example?

On Python 3 you write a range that includes the emoji you want to match, and you're done. On Python 2, that regex may or may not compile, depending on what sys.maxunicode is. If sys.maxunicode is 65535 you have to fall back on a different complicated regex that has a bunch of cases to find emoji in their UTF-16 representation. If you want to avoid that system-specific behavior, you can I guess encode it to UTF-8 bytes and write an _extremely_ complicated regex that finds emoji in UTF-8.

This is my prime example about how something that's easy on Python 3 can require horrible hacking on Python 2. A wrapper library doesn't fix that problem.

Python 2 and 3 have different semantics, and the only way a correct, automated translation between them would be possible would be to emulate one inside the other.

</comment></comment></comment></comment></comment><comment><USER45> Slightly tangential, but: I've noticed an interesting parallel between the 2.7 / 3.x partisan divide, and the US political partisan divide. In both cases, as partisan passions have increased without relief, there's both A) an increasing unwillingness to agree on basic facts about reality essential to the debate, and B) increasing presumptions of bad faith on the part of their opponents.

Examples of A in this discussion:

\- Disagreements about the degree of library support for 3.x

\- '' the ease/value of porting from 2 to 3

\- '' the rate of industry adoption of 3 for new projects

\- '' the degree to which people are driven away from Python entirely because of the version situation

Examples of B in this discussion:

\- Claims of paternalism on the part of GVR/ the PSF in pushing 3

\- Claims of unreasonable/emotional attachment to 2 by partisan devs

\- Claims of willful distortion of facts by both sides (see A)

\- Claims that the writing is on the wall for 2, because usage of 3 is supposedly accelerating

\- Claims that the writing is on the wall for 3, because it's supposedly taken too long to drive not enough adoption

It seems outrageous to suggest that the differences between 2 and 3 are anywhere near as significant as the differences between, say political conservatism and liberalism, and yet the level of partisanship seems nearly the same. How did it come to be like this?

<comment><USER46> +1

I like how your comment stands out as being such a rational, non-aggressive observation in all this. I wish I had the answer for you, but I can't figure it out either. _shrug_ Maybe some people are using this as an opportunity to vent the frustrations they've had with using the language (despite it being so loved, and ranked 3rd in most-used according to IEEE), and since there are two versions of the language instead of one, they can more readily create an object doomed for the epitome of their hatred, the sacrificial lamb going to the slaughter (sounds like something from a bizarre school of thought in psychology). You'd think it'd just be easier to let people do what works best for them. I'm sure many expect to take collateral damage from the differences in versions (imagine being a Python 3 fan and having to start working for a company that exclusively uses Python 2 or vice versa), but these people also readily accept working with languages with radically different designs and welcome in copy-cats (like Clojure is to other LISP-like languages). The important thing is that the language does what you need it to do. The name on the download link shouldn't make that much of a difference. The world has adapted to accepting Python 2 and Python 3 regardless of the bickering. There's room for "Python 2.8", even if it is poorly-named. I imagine there are probably dozens of Python 2.8s in existence - they just haven't been noticed by people here on HN. Besides, in about 3 months, we probably won't be hearing more about Python 2.8 anyways unless someone else decides to use it.

</comment></comment><comment><USER47> Thanks for doing this! I took a look at the arguments underlying the proposed switch to Python 3 and came to the conclusion that they did not meet the necessary threshold of effort to switch. Instead, I want to see every feature in Python 3 backported into 27. I don't think the unicode change can be accomodated, but 99% of the rest of the new features in 3 can.

</comment><comment><USER48> IMHO, Jython 3 would be more useful than Python 2.8, but it's your project.

We have a project at work and the only reason we need to support 2.7 is because we want to run under Jython.

Anyway, I would like to hear other people's use cases for Python 2.7.

<comment><USER49> Isn't Jython (generally) dead? The main site seems to be stuck in 2015.

<comment><USER50> It's not dead, it's just really slow. The 2.7 release has been very long in the making, released only 18 months ago. There are stabilization releases to it still coming out. There's a tiny, but dedicated group building it and it shows. Jython 3 is possible if you're willing to put your money where your mouth is.

<comment><USER51> There's been an imminent 2.7.1 release for a while now, so that will likely eventually ship.

AIUI, some of those who were paid to work on it previously are now doing so only in their spare time.

<comment><USER52> Yes, that would be true on all counts :) as one of those Jython maintainers. Jython 2.7.1 is currently bottlenecked on finalizing support on Windows for pip/setuptools. It should be the last fix.

</comment></comment></comment></comment></comment><comment><USER53> The discussion is a nice overview how py3k crowd just steamrolls over any discussion that there are indeed inherent difficulties with forcing lossy conversion of imperfect outside input.

See example in the fine manual: [https://docs.python.org/3.7/library/urllib.request.html#exam...](https://docs.python.org/3.7/library/urllib.request.html#examples)

You are only told "we know python.org uses utf-8 so just decode it as utf-8." No further discussion, no pointers are provided how to correctly fetch an URL with text content into a string. Even small convenience function that at least tries to look on Content-Type: header would help here!

I am well aware that "in py2k it just worked" was mostly an illusion. But honestly, is the situation above an improvement?

</comment><comment><USER54> Nobody should believe me, but I kind of expected something like this would happen. People just wants to keep using 2.7, and let the language evolve slowly over time, as is happening with PHP, for example. So if 2.7 development was officially stopped, someone will continue with it unofficially.

</comment><comment><USER55> I think the problem for me is that they did these changes and made a big song and dance about Python 3. If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate.

PHP has been successfully deprecating features for decades now and cleaned up their code base; they have never had a schism in the way Python has so you can argue all you want about legacy, or people preferring 2.7. The reason this happend (and is still happening) are human not technical.

<comment><USER56> > If they had have called Python 3.0 v2.9 instead everyone would have been > clear they had to migrate. [...] The reason this happend (and is still > happening) are human not technical.

You know, as a strong proponent of Python 3.* (it's a significantly better Python), I started to write a withering critique of your statements here (and I do strongly disagree about naming it Python v2.9). But then I started actually looking at the evidence.

For example, when you go to download Python at the python.org website, you're _still_ presented with a choice between Python 2 and Python 3 side-by-side, looking for all purposes like equivalent choices (Python 2 should be much less prominent and toward the bottom and/or the download button should be much smaller than the Python 3 download button)[0].

And then, when you follow the link for "Wondering which version to use?", you get a full page worth of hemming and hawing, and cost-benefit analyses and so on[1]. In fact, they should be saying something like:

        Always use Python 3 unless you have a strong reason to do otherwise.
        This typically only applies to people who have large legacy code
        bases and are for some reason unable to upgrade, or else need a special
        legacy library only available in Python 2 (most libraries are
        available in Python 3)."

So wow, having read the official python.org statements on the Python 2 vs 3 issue, I'm pretty appalled. No wonder some people who are relatively new to Python are confused or surprised. I'm on Debian or Ubuntu mostly and so download Python via package manager or PPA, or build from source. So I had no idea.

It's also been a huge mistake for GVR to have allowed so many new and attractive features to be backported to Python 2.7. It's taken away a significant amount of incentive for people to make the move. Python 2.* should have been bugfixes only for a long, long time now.

That said, if you're in charge of significant amount of Python code for a company and you've not seen for years that Python 2 is a deadend, you've either been engaging in wishful thinking or oblivious to what's happening in the Python community.

0\. [https://python.org/downloads/](https://python.org/downloads/)

1\. [https://wiki.python.org/moin/Python2orPython3](https://wiki.python.org/moin/Python2orPython3)

<comment> Al-Khwarizmi _It 's also been a huge mistake for GVR to have allowed so many new and attractive features to be backported to Python 2.7. It's taken away a significant amount of incentive for people to make the move._

The idea that Python 2 needs to be sabotaged and the community forbidden from improving it so that people makes the move, with the people who are stuck to Python 2 codebases held as hostages, should be an indicator that something was done very, very wrong...

Personally, I'm neutral as to 2 vs. 3, I use both, but the schism is the main drawback of Python for me and it often drives me to just use other languages. Python 3 is great and has very neat improvements, but it should have just been called a different name so that both branches could evolve freely and compete on their own merits, rather than on the PSF mandating to use one over the other.

</comment></comment></comment><comment><USER57> > I've been working on Python 2.8 (not an official Python release) because I > want to give all the people who use Python 2 access to the Python 3 language > features, which I think are actually pretty cool.

Theres a module called __future__ for exactly this purpose

</comment><comment><USER58> I hope I don't come across as too obtuse, but it might still make economical sense for the PSF to backpedal on their decision: even if Python3 is a good solution for the future, it's caused years of arguments and still hasn't been adopted by the majority[1].

Ridiculous as it might sound, that implies it would actually take less work to devise a path for Python2 that's backwards compatible but still has a future, and invest the time to backport all 3-only code, than it would to proceed with killing off 2 and porting everything over. It's also nothing more than everyone whose code is 2-only is being asked to do sometime in the future (they chose "the wrong competing standard" and have to pay the cost). Either way someone has to foot the bill for a unified Python but couldn't it just be that the early adopters of 3 could pay that cost if it saves updating (say) twice as much legacy code in favour of backporting the 3-only code?

Of course, the future version of Python should be the best form of the language with the right features, and that's why it was decided to kill off 2, but if after this many years the initiative hasn't completely succeeded, there's always the option to reverse course.

Heck, in the time until Python 2 is officially gone, maybe this new fork will evolve into a better language than 3 and still be backwards-compatible with 2!

For now I'm sticking with 2.7 for as long as I can but will just accept it when the time comes.

[1]: [https://mobile.twitter.com/vlasovskikh/status/80172061331236...](https://mobile.twitter.com/vlasovskikh/status/801720613312364544) for example (I don't _think_ I've made a controversial claim here but could be wrong)

</comment><comment><USER59> Now you're just adding on more technical debt for users of Python 2. Who's going to maintain your Python 2.8? What happens when there are conflicts between your Python 2.8 and Python 2.7?

This is just a really bad idea IMO.

</comment><comment><USER60> this is incredible - give me unicode support in python 2. asyncio ? probably .. i'll still be happy with gevent. This is a clear path for a python upgrade.

<comment><USER43> > give me unicode support in python 2

Nope. Can't be done without getting Python 3 either way, because _Python 3 's text model is not compatible with Python 2's_. That is why the core team allowed the other breaking changes, because software was going to be broken in the first place.

<comment><USER60> not entirely true - [http://python- future.org/unicode_literals.html](http://python- future.org/unicode_literals.html)

it's not 100% seamless, but its almost there.

<comment><USER61> > Changing to `unicode_literals` will likely introduce regressions on Python 2 > that require an initial investment of time to find and fix. The APIs may be > changed in subtle ways that are not immediately obvious.

Unless you're willing to put in the time and energy to extensively test, this is basically a recipe for disaster. You're basically paying at least 80% of the cost of a full Py2 -> Py3 port (since looking for regressions is a huge part of that cost), for only a fraction of the benefit.

<comment><USER28> Being able to change things in one part of the code base at the time -- or one feature/data field at the time, is a HUGE thing. For production systems you just cannot put the backlog on pause for a month or two while porting. You can however incrementally fix over the course of some years.

<comment><USER61> That's probably true, but unicode_literals isn't the right tool to make an incremental port, because it neither obeys good py2 _nor_ py3 text handling conventions.

It would become a substantial detour and end up being a kit more total work.

Also, porting can be done in parallel to normal dev. You aim your port at a specific release while you continue fixing bugs. When the port is done, you port over all the patches. Repeat until port and original version converge.

<comment><USER28> Isn't it as simple as a) do proper string handling in py2 unicode and b) if you write more u"" in a file than "", flip the switch and write "" and b"" instead?

<comment><USER61> Not quite, because the py2 library is often not compatible with unicode literals, and also because if you flip the switch in a module it changes the API of any functions that returned strings. That might break calling code from other modules.

So then you might have to add code to work around these issues, code that is needed in neither pure py2 or pure py3 -- hence making it a weird detour.

 _In general, it is more compelling to use `unicode_literals` when back- porting new or existing Python 3 code to Python 2 /3 than when porting existing Python 2 code to 2/3_ [1]

[1] [http://python-future.org/unicode_literals.html](http://python- future.org/unicode_literals.html)

<comment><USER28> Right.. our codebase is already unicode all over the place because otherwise we could not i18n properly. So we basically have py2 unicode-correct code with encode/decode in the proper places for interfacing witg stdlib. I didn't consider people might use str and not unicode for text..

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER62> We should make this Python 4.0 and move on. Some high paid google engineers working the "official" 3.x will be pissed, but that's life. I am sad to see the schism in Python community.

<comment><USER63> A non-trivial number of people seem to want this, but why does it need to be called Python? Keep the syntax and C extension compatibility, but ditch the name. One could even work out a means of selectively bringing in ideas from elsewhere:

\- Concurrency from Erlang ([http://queue.acm.org/detail.cfm?id=1454463](http://queue.acm.org/detail.cfm?id=1454463))

\- String handling from Go ([https://blog.golang.org/strings](https://blog.golang.org/strings))

\- Lightweight data classes ([https://kotlinlang.org/docs/reference/data- classes.html](https://kotlinlang.org/docs/reference/data-classes.html))

\- Syntactic macros from Nim ([https://hookrace.net/blog/introduction-to- metaprogramming-in...](https://hookrace.net/blog/introduction-to- metaprogramming-in-nim/))

\- more from Lua, Julia, Scala, and Haskell (within reason)

There are already plenty of examples of Python modules that implement significant modifications (e.g. Cython, Rpy2, Dask), so I don't think it would really feel all that different from typical Python programming.

</comment></comment><comment><USER64> Why did Python 3 not ship with

        from __past__ import bytestring_literals, loose_comparison, integer_division, ...

? Being able to upgrade one file at a time to Py3 would have made porting so much easier! I realize some things could be hard to support file-at-a-time, but others (like my examples) would obviously not.

I've held off on porting the Py2 code that I'm responsible for because of the lack of total test coverage. I know that something tricky with unicode, None comparison, or the list->generator split will cause a failure in a weird, untested edge case. If I were making a numeric library, that'd be one thing. However, I mostly write complicated business logic API glue code that is hard to test without huge amounts of mocks.

Also, this kind of thing gives me nightmares about porting:

        WSGI therefore defines two kinds of "string":

        "Native" strings (which are always implemented using the type named str ) that are used for request/response headers and metadata
        "Bytestrings" (which are implemented using the bytes type in Python 3, and str elsewhere), that are used for the bodies of requests and responses (e.g. POST/PUT input data and HTML page outputs).

So according to the spec (!) WSGI headers MUST be `str` in Python 2 & 3, but that means that the semantic meaning of the types changes. How on earth am I supposed to write good code for working with headers (let alone mocking and testing) when I'm required to decode them in Python 2 but not in Python 3?

</comment><comment><USER65> I consider the fact that 2.7 isn't getting new features a good thing. After a point, every new feature takes away something from everything that came before.

</comment><comment><USER66> What about contributing towards a project which enables python2 code to run in python2? Seems like this would help the move to python3 overall...

Something like this? [http://python- future.org/translation.html](http://python-future.org/translation.html)

<comment><USER43> > What about contributing towards a project which enables python2 code to run > in python2?

Surely that already exists?

</comment></comment><comment><USER67> I never knew that despite Python 3 is called the future by PSF and has been around for a ling time, people still want to stick to Python 2. I mean it isn't the 2013 that libs aren't ported, most famous ones generally are ported. Don't know what the problem is.

<comment><USER16> Legacy python 2 code & an unwillingness to refactor it for python 3.

<comment><USER67> I can understand a project with millions of lines of python2 code, it would be a headache to port it all to python3

</comment></comment></comment><comment><USER68> Haha... this is the most Python thread ever.

</comment><comment><USER69> So it begins.

The arrogance and stubbornness of the CPython dev team is starting to face the consequences we all knew were coming. If only they'd at least done unicode right. Gone with assume UTF-8 and kept the indistinction between bytes and unicode, more of us would be onboard.

</comment><comment><USER70> Why does Python have so many hilariously convoluted trials and tribulations over decades trying to upgrade their language when the JavaScript community is able to run smoothly across many different versions and many different interpreters simultaneously?

</comment><comment><USER71> Just don't call it Python 2.8

<comment><USER71> PLEASE don't call it Python 2.8 ...

</comment></comment><comment><USER72> It's too bad someone didn't do this years ago. We could have avoided much pain.

</comment><comment><USER73> As a Python 2.7 project why would I trust more to this unofficial version with a lot of backported code compared to the tried and tested 2.7 to 3 route?

What would happen with my python 2.8 when it needs to be converted to the official python 3?

</comment><comment><USER63> > there are some python scripts that will run under both Python 2.7 and Python > 3.x but produce different output

OK, so it may well be terrific, but it should _really_ have a different name.

</comment><comment><USER74> You need one of these. [https://golang.org/cmd/fix/](https://golang.org/cmd/fix/)

</comment><comment><USER75> the python community is like a snake eating its own tail

</comment><comment><USER76> Just call it Unofficial Python 2.8 instead of Python 2.8

</comment><comment><USER77> The existence of this project shows a tremendous lack of judgment on behalf of the creator and does exactly zero good things for the python community.

</comment><comment><USER78> Just a couple of things I want to point out here.

1\. Calling it Python 2.8 is a really bad idea. If you want to fork Python in this way, great. I'm sure very few people in the community would have a problem with it if you called it Brothon or P8thon or Hackthon (could run into trouble with that one, but who knows?) or IHate3.xThon. You can call it LifeOfBrython or Snake, depending on how much you care about where the name came from.

Guido van Rossum is one of the least litigious people you can find in the open source community. When he wanted people to stop naming packages after PEPs (pep8, pep257), he didn't try to go to court and figure it out later. He talked to the maintainers of the packages and explained why he thought it was problematic [0]. I wouldn't expect a cease and desist showing up anytime soon, but it's in poor taste, and I hope you reconsider it. Python is not yours just because you are free to use it and do as you please with it. It's really stretching the concept of open source for you to unilaterally declare a collection of hacks to be a point release that's been specifically addressed and decided against by the community as a whole.

2\. I have so much sympathy for people who must maintain Python 2.x applications and cannot make the business case for putting the time into porting it to Python 3. I'm in that situation myself right now, and I have been for years. I can't find a compelling argument to warrant the time so long as the 2.7.x branch is getting security updates. When the security updates stop, the move will finish.

The reality is that those of us who have been working with Python for a long time now (10+ years) have already figured out reliable workflows to get around the most lacking aspects of the language in our domains of expertise. Or we have swapped out subsystems in other languages for cases where we absolutely cannot find workarounds.

I get it. I'm in that boat. I understand that boat because I live in it.

I can even understand why this project happened. Because hacking things you love to make them better for you as an individual is the heart and soul of what makes software development so great.

What I absolutely cannot understand is why anyone (absent certain libraries needed) would start a new project on a deprecated branch of a language. And I don't understand why this is such a contentious issue specifically with Python. I don't hear any of my friends who work with C# or Go getting into arguments about how the latest version has failed or shouldn't have been rolled out. As much as Swift 3 has caused problems, I don't hear any of my iOS developer friends complaining about how that shouldn't have happened and trying to backport the good stuff into the 2.x branch. I genuinely don't understand this behavior in the Python community.

 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __*

I do, however, suspect that it has something to do with the overall age of the community.

Using Python has always been a matter of taste and style. I get that. Python is a language that makes explicit tradeoffs between performance and style. It is no shock to me that people who learned to love the language in its older form want it to stay that way. And I say this as someone who is closer to 40 than I am 30: we older folks in the industry need to fight against the stereotype that we can't or won't learn new tricks. Yes, there's a place for battle scars and pushing back against every new flavor-of-the-month stack that rehashes old problems in new ways. But obstinately sticking with stuff simply because it's what we know does all of us who are getting on in years a huge disservice.

Getting a good gig as a software engineer in your 20s is not that difficult. Getting the same gig when you're pushing 40 and the hiring managers are still in their 20s is a lot harder. If you're making decisions to start new projects on old versions of _any_ language, please, please, please, do all of us a favor: make sure that you are doing it for solid reasons and not simply because it's what you already know and are already comfortable with.

 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __*

Because this post isn't long enough already, I have a second pet theory about the reluctant adopters.

Python 3 is a _great_ language. It's not the same as Python 2. It makes different tradeoffs about styles and choices of expression from what Python 2 does because these things can and should change over time.

I think that the expressive power of Python, the closeness to human language, and the ease of reading well-formed code have a lot to do with the resistance to Python 3. There are people (I'm one of them) who get really really picky about language in general. I think the Oxford comma is a necessity in almost every case. And I think people who casually omit it are stupid, shallow, non- thinking, drones who don't care about the history of language and don't care about precise meaning of words, and therefore don't care about me because they an't be arsed to toss a comma in a place that greatly clarifies meaning.

I don't actually think all of that, but I'm closer to that than I am to not caring at all.

And there are many like me. When you're dealing with a programming language with intent at its heart, people are going to take that in different ways. When you're dealing with a language that cares about whitespace and eschews braces and wants to limit brackets and just expose the pure logic of the program, people really are going to get fired up about print vs. print().

That's expected. And beautiful that so many people care that much. But as much as I lean towards prescriptivism and that rules are good for a language, even I have to admit that language evolves. But it usually evolves to be more inclusive and more expressive, not less. The really bad fights about languages in general revolve around what to include, not what to exclude. Because languages are exclusive by default.

A counterpoint to my idea above that we are all just old and lazy, is this: that we really do genuinely care, and that we care for good reasons. But something has to give. We cannot refute the evolutionary pressure. Python 3 is as necessary for modern speakers of programs as a recent edition of a dictionary is in your preferred language.

Yes, you can get by with something older, and you can even make yourself understood by most people who speak the language.

But you are limiting your ability to express your intent when you make an intentional choice to refuse to adopt what the rest of the culture around you is doing.

Aaaaaaand I'm done. Sorry for how long that was. I didn't intend that. It just sort of happened. If you read all the way to the end, let me know, and I'll upvote you.

[0]: [https://github.com/PyCQA/pycodestyle/issues/466](https://github.com/PyCQA/pycodestyle/issues/466)

</comment><comment><USER79> Please just spend your time porting things to python 3, this kind of work could spell the end for python

</comment><comment><USER80> Hmmm. OK.

This is a bad idea. My guess is the author will not be able to call this thing "Python", and for good reason.

Should it exist? Sure. Why not? The nature of FOSS is that anyone can tinker with it and make it into whatever they dream. Go for it! Just don't call it Python.

I use both 2.7 and 3.x. No drama. New projects go through a "Do we see any issues with 3.x?" phase where we try to list libraries we'll need and check for support. Not that difficult.

I absolutely understand companies/people holding on to 2.7 for dear life. Converting a non-trivial working code-base would be costly and very difficult to debug if that code base doesn't have extensive test coverage (probably true of most). It would also be utterly irresponsible in most business cases.

Most businesses don't have software developers sitting around doing nothing. Revenue comes from existing products and new features along with bug fixing. No customer of a software product will pay one dime for a company devoting a year to port their entire code-base to 3.x. Can you visualize that announcement?

"We stopped delivering new features and fixing bugs a year ago. Instead we ported our entire product to Python 3.x. Today, a year later, we give you exactly what you were using a year ago. Enjoy!"

Yeah. Exactly. The huge sucking sound you'll hear is that of customers leaving the company throughout an entire year of nothingness. In a dynamic free market competitors would eat you alive as you stop delivering features and fixes while they zoom right past you with a better offering to your customers.

That said, sticking to 2.7 for the long haul --say, ten years from now-- will create the Python equivalent of old COBOL code still running in deep dark places within financial institutions. It will create codebases nobody wants to look at or touch. It will create codebases that will be anywhere from hard to impossible to support as libraries will surely evolve to support the 3.x and, eventually, 4.x branch.

It is perfectly sensible for a company to, given today's realities, stick to 2.7. This is almost exactly the problem described in "The Innovator's Dilemma". Good management means focusing on delivering what your current customers are buying and want to buy. Unless they are clamoring for your product to use 3.x it could actually be really bad management to make the switch.

The only way to do it correctly would be to hire a full parallel team of programmers to port the codebase while mirroring every single new feature and bug fix implemented as customer's needs are met. At some future point the two branches would achieve parity in function and reliability. This parity would allow seamlessly switching to the new codebase without damaging customer relationships. Of course, this would cost a ton of money for a non-trivial product and, at the end of the process, the company would probably have to fire one of the two teams. Pretty messy and costly in more than just financial terms, isn't it?

I am not advocating either approach. Just saying I understand this from both engineering and business perspectives. People pushing others to just switch are doing so from a frame of reference devoid of any understanding of the realities of business. Most businesses are not about the technology, they are about what problem you solve for your customer. They don't care about "the geek stuff" behind the curtains. And rightly so.

Live long and prosper.

</comment><comment><USER81> Is the xkcd Appropriate Standards strip appropriate here?

<comment><USER46> Python xkcd: [https://xkcd.com/353/](https://xkcd.com/353/)

What's even ironic here is that the print command he used is Python 2 instead of Python agnostic. I wonder which version Randall Munroe would prefer, if either.

</comment></comment><comment><USER82> Program languages could be so great if it were not for those pesky users.

</comment><comment><USER83> This isn't bound to confuse anyone.

<comment><USER84> This comment wasn't ironic

</comment></comment><comment><USER85> Hope you don t succeed

</comment><comment><USER86> Cuz you have too much free time?

</comment><comment><USER87> This is gonna be great.

[https://vazor.com/drop/gif/bill_hader_popcorn.gif](https://vazor.com/drop/gif/bill_hader_popcorn.gif)

<comment><USER87> I meant -- entertaining great -- people see Python2 vs Python3 as a holy war, it's just software guys.</comment></comment>


Ask HN: User friendly book writing software - <AUTHOR>

Hi, I have a book idea and will need to format pages in odd ways similar to how "Ripley's Believe it or Not" books are formatted. I wanted to know if their is any extremely user friendly and cheap MAC software that would allow me to place images and format in this manner. I am avoiding taking the Adobe route until I have to. I don't want to pay that much and it seems more complicated than it has to be. I want something that's fast, simple and cheap.!
Thank you!
BTW - if this doesn't exist it might be an idea for some of you developers to create :) <comment><USER2> Have you tried the free trial of Pages from Apple?

<http://www.apple.com/iwork/pages/>

<http://www.apple.com/iwork/download-trial/>

It's a combination word processor and page layout program. Not sure if it does everything you need, but it's probably worth a try.

<comment><AUTHOR> Thanks .. this seems "good enough" for what I was looking for

</comment></comment><comment><USER3> You might try LyX ("lick"): <http://wiki.lyx.org/Mac/Mac?from=LyX.LyXOnMac>

It's basically a fancy front-end for LaTeX, and might do what you need. The printed output would certainly look nice.</comment>


Why you should never be a startup girlfriend - <AUTHOR> http://stephfinch.com/2008/07/why-you-should-never-be-a-startup-girlfriend/ For all of you ladies who may or may not be flirting with the idea of dating a startup programmer, you should know exactly what you're getting yourself into. <comment><USER2> There's something about lists like this that bother me. I know it shouldn't -- it's meant to be light and humorous. I think what bothers me is that the person she describes is really, godawful boring.

The line that stands out for me: "If you want to understand your boyfriend, understand computers. It's not that difficult."

I...I just don't know. I'm an engineer at an early-stage startup and computers are a big part of my life, but I certainly hope they're not the best way for my girlfriend to understand me.

I'm not ribbing the article. It's cute. But when I read it I cringe and maybe worry a little bit that I actually _am_ like that.

I'd also feel terrible if I treated my girlfriend like that.

<comment><USER3> _...and maybe worry a little bit that I actually am like that_

So? No where in the article do I see her _complaining_ about anything. I am an "engineer" at a startup as well, and I have never treated a girlfriend poorly. She wouldn't skip work to spend time with you and you can't either. The difference is you work far longer and less set hours than she does. When you're building or running a business you have to be realize that there are people in _that_ relationship that are counting on you, likely for their livelihood. Due to this fact, "dates" become less important than keeping the website up because missing a date doesn't cost you hundreds or thousands of dollars -- and it keeps the people you work with from becoming frustrated or angry by your lack of proper priorities.

I exhibit many of the tendencies she describes in the article, albeit toned down to a less extreme level (I would never do an SEO campaign for a gf's birthday site (or make said site), for example). Saying "If you want to understand your boyfriend, understand computers" is accurate so long as you take it to mean, to understand what he talks about if you ask about work or what's causing stress, etc. In previous relationships, sometimes the woman took a genuine interest in what I did, wanted to learn a bit about it, etc. Others would just affectionately tell me I'm "such a nerd" and tell me to come back to bed. Either way, it requires understanding on their part.

As for being boring, I can honestly say I've never had a boring relationship. Just because she works at a bank doesn't mean she's boring, just like coding doesn't make you boring. It's what you do with the time you're together that matters. In general, it's what you do when you're _not_ working that makes life exciting and adventurous. Your profession should have nothing to do with that (unless you're an international assassin or something, then it's always exciting). An old friend of mine, who barely ever uses his computer, has routinely been described by his girlfriends as an extremely boring person. He doesn't like going out and would prefer to just lounge around his apartment all day and play video games or watch TV, regardless of whether or not his girlfriend is there. I have never once been with a woman and said "lets just sit around and you can watch me play this game." You're making assumptions based on outdated stereotypes.

Yes, in general "we" are highly technical, logical people. We like challenges and taking risks. We hate mediocrity and lose interest in anything as soon as it becomes boring. We can be very passionate, opinionated and headstrong. We have a constant desire to learn and grow in new ways.

Now, what in the hell is bad about that?

<comment><USER2> I read your response and the other thread of replies and all I can think of is this:

since feeling is first / who pays any attention / to the syntax of things / will never wholly kiss you

</comment></comment></comment><comment><USER4> Ah yes, "the zone".

Whenever I start living with / working with / dating someone I always make sure to warn them about "the zone". I've been known to completely tune out everything around me to the point that it takes someone waving their hands in front of my face to get my attention.

I try to tell people it's nothing personal, and I'm not consciously ignoring them, but I don't know if they believe me. The worst is when I realize 5 minutes later that someone was trying to get my attention and gave up.

</comment><comment><USER5> Or... "why you should never date someone who writes blog posts named 'why you should never be a startup girlfriend'"

<comment><USER6> +1, correct use of quotes.

</comment></comment><comment><USER7> I guess someone needs to write an article for the 1% of people who fall into the "startup boyfriend" category.

I appreciate men who understand computers, use Macs (or, well, I'm platform agnostic but prefer !windows), know what twitter is, and will wait in line with me to get a new iPhone. :)

</comment><comment><USER8> Buried for innaccurate title. She concludes that she actually enjoys being a startup girlfriend.

Oh wait this isn't digg. Up arrowed.

</comment><comment><USER9> For those of us that are single...

Does a single girl out there EXIST that could understand even a few of these items? Particularly the one about weekends?

I've scoured my campus and I have yet to find one.

If(oneExists) { letMeKnow(); } else { sigh++; }

<comment><USER10> We exist.

<comment><USER9> where have you been all my life? =O

</comment></comment></comment><comment><USER11> > "You will have to appreciate the time and effort it took to run a search > engine optimization campaign on the website he made you for your birthday, > and how important that is to him. He shows his affection differently than > other guys do sometimes."

That's funny.

</comment><comment><USER12> Many of these points are nullified when you find a girlfriend that is also in the startup world. Share the pains and joys together!

<comment><USER13> true and better you both read HN sitting opp each other sipping coffee :)

</comment></comment><comment><USER14> All I know is that _Startup Girlfriend_ is going to be in the title of my next product.

</comment><comment><USER15> "~Own a Mac or be willing to admit that you should."

Who codes on a Mac?

<comment><USER16> I do, I used to code on a laptop running gentoo but got tired of spending too much time working as a sys-admin on my own system...

Now I use a mac and use prefixed portage to manage all the unix apps I use.

<comment><USER17> You use portage on a mac? How? Got a link?

<comment><USER18> It's not not a port of Gentoo Portage, but here's something similar: <http://macports.org>

There's also Fink, but for some reason I didn't like it when I first tried it (over 2 years ago).

</comment></comment></comment></comment><comment><USER19> Why you should never be a girlfriend: relationships usually end painfully

<comment><USER20> Ah. Don't make me break out the Tennyson.

"'tis better to have loved and lost, than never to have loved at all."

Sorry, I had to!

<comment><USER19> "'tis better to have loved and lost 5 times, than never to have loved at all."

Is this version true too?

<comment><USER21> Yeah, you need to iterate to refine the process.

<comment><USER19> If every iteration hurts then is iterating a lot really a good plan?

In each iteration one believes this is the final iteration that will last forever. If not, you're doing it wrong. How is that compatible with planning to iterate?

<comment><USER16> It's the same as creating a company... If the failure rate is high, trying more than one time bring the failure rate down... But when you are creating a company if you start by thinking that it's going to fail, you are already out of the game ;-)</comment></comment></comment></comment></comment></comment>


'We cannot make a living': SF cabdrivers' debts mount amid Uber, Lyft battle - <AUTHOR> https://www.sfchronicle.com/business/article/We-cannot-make-a-living-SF-cabdrivers-14371923.php <comment><USER2> This is just anecdotal, but I've found yellow cabs in SF in the past 4 years to be some of the worst cab experiences I've had anywhere. Drivers saying things that make me really uncomfortable, or seeming a little unstable, also driving more recklessly than the typical Uber or Lyft driver. To the point where even if I'm in an area like fisherman's wharf now where yellow cabs are plentiful, I'd rather walk a couple blocks to a side street and call a rideshare car than take a taxi.

I know Uber and lyft are a bit unpopular on here these days but from my perspective as a rider, even aside from the convenience of hailing a ride anywhere, they are just such a better experience on average than taxis. The rating system seems to be a much stronger incentivizer of good behavior than the old fashioned taxi regulations were.

<comment><USER3> Agree. Same in most places. Tel Aviv, LA, Boston, ...

<comment><USER4> When you are a tourist, Uber/Lyft are the only way to get a fair fare.

<comment><USER5> As a former resident of NYC there is always an angle for them to scam you. Tourist or not. Get loud and crazy and suddenly the driver found change, accepts CCs, etc.

</comment></comment></comment></comment><comment><USER6> The city should not have allowed these medallions to become investment vehicles.

Taxis are unpleasant so I'm not too sad they are dying off, but I'm concerned about other areas where the city creates artificial markets that don't make sense over time.

</comment><comment><USER7> I definitely feel bad for them but they're responsible for their own decisions...They took the risk to invest into a medallion with the expectation of a return. But if the end result is crappy, it's part of the expectation.

</comment><comment><USER8> City should refund costs of medallions with a difference in the expected NPV vs. the current economics of medallions.

<comment><USER9> Can they pay out every bad investment that someone in SF has made?

<comment><USER8> City created a monopoly. When they decided to cancel the monopoly or no longer enforce it, this should be a part of any such decision.

</comment></comment></comment><comment><USER10> If medallions were worth $500k+ back then, how much were these cabdrivers making on their rides to make this profitable?

<comment><USER11> See [https://kfarr.com/2007/11/15/how-much-is-a-san-francisco- tax...](https://kfarr.com/2007/11/15/how-much-is-a-san-francisco-taxi- medallion-worth/)

Medallions in SF are capped at 1500 and the holder is allowed to lease the medallion out to others. So the holder gets around $22,000 a year leasing it out, or around $200,000 using NPV discount of 6%. Meanwhile without a medallion a cabdriver makes $24,000 / year after fees etc.

</comment></comment><comment><USER11> Similar article about NYC: [https://news.ycombinator.com/item?id=19955489](https://news.ycombinator.com/item?id=19955489)

</comment><comment><USER12> oh no that sucks</comment>


Aviate joins Yahoo - <AUTHOR> http://blog.getaviate.com/post/72586543194/aviates-going-to-get-better-faster-with-yahoo

<comment><USER2> This might be out of context, but a question though. How this companies get bought? Of course, building a great product is part of it. But are they shopping around, emailing / visiting bigger companies to buy them? Or they will just wait until some bigger company contact them and have some negotiations?

<comment><USER3> Aviate Team comes from Google (Google Play PM and Search Engineer). I would think right people at Yahoo Knew the talent and want it.

[http://getaviate.com/team.html](http://getaviate.com/team.html)

Congrats to the team. Great Product and team.

<comment><USER2> You might be right. So this is the case for Aviate. How about other startups?

<comment><USER4> I am sure the same is true for all the other acquired companies. If you look through all startup acquisitions, the pattern is the same. You rarely see startups that haven't raised capital get acquired, unless they are actually successful.

</comment></comment></comment></comment><comment><USER2> Congratulations to Aviate. I think they're just a new company, I'm not sure.

I really love their home screen and I was afraid that Yahoo might shut them down. If that's the case I don't have anything to replace from Aviate. I like the combination of Aviate as home screen and Cover[0] as my lock screen.

[0] [https://www.coverscreen.com/](https://www.coverscreen.com/)

<comment><USER5> I've really wanted to try it, but never got a beta invite:)

<comment><USER2> You now have a chance. They are giving away some codes right now: [https://www.facebook.com/aviateapp/posts/195912073936304](https://www.facebook.com/aviateapp/posts/195912073936304)

<comment><USER5> Sweet! That did the trick.

</comment></comment></comment></comment><comment><USER6> > Today, we are absolutely thrilled to announce that Aviate is being acquired > by Yahoo. Don't worry, Aviate isn't going anywhere.

</comment><comment><USER7> whats the over under for companies that get purchased by google/yahoo/apple/microsoft and never see anything more from them?

<comment><USER8> I think it depends on how much they pay for it. If the price is high, then they want the product. If the price is low, they want the people. Of course even if the price is high, sometimes companies muck it up anyway.

<comment><USER9> If the price is high they want the user base.

I don't think big companies care too much about a product in itself. They care about the team (which created a good product) and/or a userbase.

<comment><USER8> Good point - I hadn't considered the userbase. But don't they lose the userbase if they crap on the product after it's been acquired?

<comment><USER9> Absolutely. I consider that a failed acquisition -- which many companies do. Yahoo!, for example, had done this a lot in the past with their acquisitions.

</comment></comment></comment></comment></comment><comment><USER10> It's not a bad product, but they don't actually care for treating even bug reports of the most simple and obvious kind respectfully. Somehow i doubt merging into Yahoo is gonna fix that.

</comment><comment><USER11> Now, how long until they close down?

Yahoo has repeatedly proven it is not a safe location for any service; it is even worse than google in that respect.

</comment><comment><USER12> I'm interested to know if this activity will bring any viability or perhaps tempt Apple into allowing greater access to their lock screens?

</comment><comment><USER13> Can someone please explain why these corporations buy companies for a product they can build themselves for (usually) less money?

<comment><USER14> They don't buy the product they buy the team and their vision.

<comment><USER15> Perhaps most importantly: They bought the userbase.

<comment><USER16> How would Yahoo! acquire the user base in this case? By putting more Yahoo! apps on the screen? But users need to install them in the first place.

</comment></comment></comment></comment><comment><USER17> I've been using this for the past few weeks and like it. Hope yahoo lets them continue on their own.</comment>


Minecraft link to net's biggest botnet - <AUTHOR> http://www.bbc.com/news/technology-38678466 <comment><USER2> So the link is that someone claimed he got attacked and claimed as well that someone bragged about that attack? No proof or anything? I kind of miss what the article is trying to say honestly.</comment>


Ask HN: How do I reverse engineer my country's Smart ID Card - <AUTHOR> I'm from Pakistan, and we recently had our National ID cards updated to the Smart National ID Card (SNIC).
Trouble is, despite have a chip like a smartcard, there is no documentation on the Smart Card, or the "Smart" functionality of the card.
I'm an Estonian E-Resident[1], and I can sign documents using my Estonian ID card's certificates, but nothing pops up when I plug my SNIC into the my +ID Smartcard Reader[2].
I'm a developer, and fairly competent at learning new things, but there's no straightforward guide on how to read the data on my ID card.
Could you provide any resources I can look up to find out what this piece of plastic is capable of?
[1]: https://e-estonia.com/e-residents/about/
[2]: http://www.pluss-id.com/ <comment><USER2> It seems to me that a good starting point would be the Pakistani government agency responsible for the card and its use.

Good luck.</comment>


Ask HN: Who should I follow on Twitter? - <AUTHOR> I've had difficulty "getting into" Twitter, but I can see other people in the industry can derive real benefits like learning, getting exposed to new ideas, keeping up to date on industry happenings, etc.
I'd like to give it another shot with a curated list of accounts to follow.
I work primarily on web apps but am open to learning about other things in the tech space.
Who would you recommend following? <comment><USER2> Nothing comes for free, you will need to work on it ...

1\. Do a search on terms that interest you;

2\. Pick a few names and follow them;

3\. See who they re-tweet, and follow them;

After a week ...

4\. Pick a pointless tweet, and unfollow that person;

5\. Do that again until you are following half as many people;

6\. Lather, rinse, repeat.

After 2 months, write a blog post about who you're now following, and submit the link here.

</comment><comment><USER3> People or topics you want to read about 280 chars at a time.

When I used twitter, I'd follow people like Joe Rogan, or political people.

</comment><comment><USER4> A good start: Pick someone you admire and comb through his or hers follow list.</comment>


Heap (YC W13) Raises $27M Series B - <AUTHOR> https://blog.heapanalytics.com/heap-27-million-series-b/ <comment><USER2> As a former remoter at Heap, I can only recommend them: great team, good focus, promising product.

Good luck Matin & team!</comment>


Bitcoin to be available in Austrian post offices - <AUTHOR> https://derstandard.at/2000061100326/Bitcoins-kuenftig-in-oesterreichischen-Postfilialen-erhaeltlich <comment><USER2> Translation: the post offices have a rack of gift cards (iTunes, etc) - BitPanda are selling Bitcoin and Ethereum cards there too, cashable on their exchange.</comment>


Electrons flowing like liquid in graphene start a new wave of physics - <AUTHOR> https://phys.org/news/2017-08-electrons-liquid-graphene-physics.html <comment><USER2> The study in question, which is much more modest in terms of claims, and much more interesting: [http://www.nature.com/nphys/journal/vaop/ncurrent/full/nphys...](http://www.nature.com/nphys/journal/vaop/ncurrent/full/nphys4240.html?foxtrotcallback=true)

Key point:

 _Notably, the measured conductance exceeds the maximum conductance possible for free electrons. This anomalous behaviour is attributed to collective movement of interacting electrons, which 'shields' individual carriers from momentum loss at sample boundaries_

<comment><USER3> Wow, could we call graphene a semisuperconductor now?

<comment><USER4> Rather than meaning "superb conductivity", superconductivity is a specific electronic state of matter in which the conductivity drops to zero at a certain critical temperature, and magnetic fields are "expelled" from the material. In conventional (low-temperature) superconductors, this is caused by formation of electron pairs (Cooper pairs) that behave as bosons. There is no established mechanism for unconventional (high-temperature) superconductivity.

In any case, the present study does not mean that graphene is a superconductor.

<comment><USER5> Conductivity drops to zero? Did you mean resistance?

<comment><USER4> Correct.

</comment></comment></comment></comment></comment><comment><USER6> Interesting that increased scattering can increase average current and electron velocity (in a fluidic state) by protecting higher velocity electrons from the edges of the flow. It allows higher conductivity than even theoretically possible in a metal.

I'm usually pessimistic of the hype surrounding graphene, but this is an interesting result. I do hope that there is a bit more room for something like Moore's law.

Some of the biggies were still investing... as of 2014.

[http://www.datacenterdynamics.com/content-tracks/servers- sto...](http://www.datacenterdynamics.com/content-tracks/servers-storage/ibm- invests-3bn-in-graphene-semiconductor-research/87785.fullarticle)

</comment><comment><USER7> Huh.

Two questions:

1\. Any chance this can be replicated in 2D topological insulators?

2\. Any chance this could work at room temperature? The paper seems to say <150K.

<comment><USER8> Tangential question: are the electron "fluid dynamics" of graphene inherently "2D" because it's such a "layered" material and we're talking about such thin slices?

That is, do vortices in the flow behave as if confined to 2 dimensions?

Even if we have to given it a nitrogen bath, it would be _incredibly_ interesting if you could experiment with 2D electron fluid dynamics just by creating graphene structures. (Which I believe can be created via laser circuit printing -- considerably easier than the process for similar things now.)

<comment><USER9> Yes but bulk graphene has a lot of imperfections changing the electron flow.

<comment><USER8> This isn't something I know a huge amount about -- could you elaborate?

(I'm mostly just unsure of the scale we're talking about -- what qualifies as "bulk" and what's "a lot"?)

</comment></comment></comment></comment><comment><USER10> Tangential: are there any commercially-deployed graphene based technologies yet?

<comment><USER9> Graphene is used in place of other carbon sources in batteries anodes [1] as well as a variety of inks [2]

[1] [https://angstronmaterials.com/product-category/graphene- for-...](https://angstronmaterials.com/product-category/graphene-for-energy- by-nanotek-instruments/)

[2] [https://vorbeck.com/pages/products- conductiveinks](https://vorbeck.com/pages/products-conductiveinks)

</comment></comment><comment><USER11> Neat!</comment>


Red Hat Is Now a $2B Open-Source Baby - <AUTHOR> http://fortune.com/2016/03/22/red-hat-revenue-2-billion-open-source/ <comment><USER2> Actually, since Red Hat is a public company, its "market cap" valuation is actually at $13.28 billion. The article merely claims says Red Hat has made $2 billion in revenue. That being said, the company does seems overvalued (P/E ratio is 70.62).

It has a positive EPS of 1.03, which is another point in its favor (it means it's actually turning a profit).

Source: [http://fortune.com/company/rht/](http://fortune.com/company/rht/)

</comment><comment><USER3> What exactly is their business model?

Call me naive (after all, I'm just an engineer), but I am shocked that they are managing to sell something that's free.

<comment><USER4> Stability of software, targeted at those who need it (eg enterprise). With a large supporting ecosystem around that.

</comment></comment><comment><USER5> Another link to fortune.com where I can't view content because I have adblock installed. Next.

<comment><USER6> Then it seems to be working out for both of you. You avoid the ads and fortune.com avoids serving content without ads.

</comment></comment><comment><USER7> I somehow feel canonical/ubuntu should be valued more, at least not too far from Redhat, they have decent software, probably just need a "better" CEO/CFO to monetize what it has so far.

Meanwhile that will drive many freemium users back to Debian when revenue becomes the priority, as what Redhat did in the past.

<comment><USER4> Unlike Red Hat, Canonical are a bad company (ethics wise), mostly sponging off Open Source projects. :(

Very few in the Open Source Community would cry if they were to disappear.

<comment><USER7> I don't know how bad it is, however I use Ubuntu on my desktop daily for free and I appreciate that, I don't see Redhat provides that though(ever since Redhat dumped Desktop users after Redhat 8/9 release many years back).

<comment><USER8> Fedora? Any of the RHEL recompiles?

<comment><USER9> Fedora would be great if they did periodic LTS releases -- and it wouldn't really take much effort, as they sort of do this now by basing a given version of RHEL off a given Fedora release. So the work that goes into keeping RHEL 7 up to date could be applied to Fedora 19 without too much hassle.

<comment><USER10> huh? Isn't that what CentOS is meant for, more or less?

<comment><USER9> Fedora tends to have a lot more available for it then RHEL/CentOS. However adding EPEL to CentOS does help a bit though.</comment></comment></comment></comment></comment></comment></comment>


Ask HN: Foreign founder, can't find a payment processor - <AUTHOR> Dear HN
I'm a solo foreign founder for a Delaware Corp, but I can't find a payment processor for my US customers because I'm in Pakistan.
The irony is that I'm building a marketplace:
- Stripe rejected me (they were nice about it)
- Paypal decided I had to be in the US despite having applied for my account while being in the US (Paypal isn't available in Pakistan)
- Braintree rejected me once, I changed my business model a bit, and now I'm waiting on a second rejection.
What does one do in this scenario? Is there another payment partner you can recommend? <comment><USER2> International currency transfers are an area where legal advice is might be worth paying for because the problems stem from legislation and the policies of US based payment processors are likely to reflect legal requirements rather than internal business policy decisions.

Long term, it probably makes sense to obtain local legal advice to evaluate the ease of entering foreign markets.

Good luck.

</comment><comment><USER3> Are you trying to have payment delivered to a Pakistani bank account? Otherwise, it seems like a US corporation with a US bank account should be able to take payments from US customers, and you could handle the problem of how to get the money to Pakistan separately.

</comment><comment><USER4> Can't vouch for this, just passing along some info I observed: [https://stripe.com/atlas/faq](https://stripe.com/atlas/faq)

<comment><USER5> This might be your best option.

I know people who gave me really good feedback about this (they incorporated in the US for your exact same reason).

</comment></comment><comment><USER6> Hi,

I have used 2checkout for years. They also accept payments from PayPal customers which helps if lot of customers want to use funds from their PayPal account.

</comment><comment><USER7> [https://www.paddle.com/](https://www.paddle.com/) ?

</comment><comment><USER8> Take a look at 2Checkout.

</comment><comment><USER9> give skrill or neteller a try

<comment><USER10> The OpenStreetMap foundation (based in the UK) has some trouble getting their money from Skrill. I can't tell if that's common and welcome anybody to counter with a positive comment/experience on Skrill.

[https://lists.openstreetmap.org/pipermail/osmf- talk/2016-Oct...](https://lists.openstreetmap.org/pipermail/osmf- talk/2016-October/003950.html)

<comment><USER9> good to know. thanks</comment></comment></comment>


Secure Website Authentication Using GPG Keys - <AUTHOR> http://neverfear.org/blog/view/3/Secure_website_authentication_using_GPG_keys

<comment><USER2> The root cert aside and with all the other ssl deficiencies all browsers support it! Usability is imo the issue if more than a handful of people need to access the site. RFC6509 [http://tools.ietf.org/html/rfc6509](http://tools.ietf.org/html/rfc6509) shows crypto independent of any PKI. Implemented running in Javasrcipt and HTML5 as open source www.certivox.org where unlike Diffie-Hellman the key agreement is authenticated. No passwords, usernames... nothing.

</comment><comment><USER3> I had a hacky wiki based on GPG-signed text files: [https://gist.github.com/Zash/3804318](https://gist.github.com/Zash/3804318) Editing was done through a shell script that fetched the source, invoked my editor, signed and uploaded the signed text back.

</comment><comment><USER4> When https was invented, we imagined that users would have personal certificates for authentication (&c).</comment>