The lack of a case against Python 3

And believe me, as an "international" person, this is profoundly annoying and has trained me in avoiding using the non-ASCII letters of my language which of course "castrates" the written language somewhat (i.e. When people use non-ASCII letters for folder names I think they are just asking for trouble - how normal is that?)

I love how upfront python3 is with the difference between raw bytes and strings. I work a lot with python and in particular I do a lot of work with serializing and deserializing stuff from/to binary blobs. Due to platform issues that I hope will change in the next year or so I can't use python3 currently but I keep all my code compatible with both and all tests should run with python2 and python3. Yes, I am firmly in the python3 camp :)

pycharm inspection definitely helps with keeping code compatible with 2 and 3.

ASCII isn't even good enough for that 10% – British people need £, which isn't in ASCII – not to mention things like em dashes, en dashes, and curly quotation marks that word processors tend to add.

I believe he meant people that have to actually deal with complications of unicode/bytestring themselves.

For most uses, you just handle "strings", and don't really care if they're unicode or not. Only lower-level libraries/apps will ever care if these strings are unicode or not.

I will use a single character to express my absolute agreement:

Edit: I guess even Lisp developers have to consider Unicode.

You're totally right that people who deal with outside-world data need Unicode. Anything that deals with users MUST deal with Unicode.

But a huge proportion of the people I work with -- in Israel, China, and Europe -- couldn't care less about Unicode. That's because they're processing logfiles, dealing with test automation and system administration. For them, Unicode is important a very small proportion of the time.

So I stand by my assertion that a small proportion of developers need to worry about Unicode. But I also agree with you that Unicode is absolutely crucial in the modern world, and that a language lacking good Unicode support isn't going to get very far.

Or jump to another language.

Here's my problem: I don't program unless I get paid, and I simply cannot sell this crazy idea: "hey, you know all that software you paid me to write? how about you pay me again so you can have it in python3?"

It seems like if I want my programs to run for more than ten years I shouldn't be using Python.

I'm not sure this argument works in your favour. You appear to be saying that the people who like Python 3 are those who have no experience of anything else, whereas the people who have experienced other things are reluctant to use it. You'd have to give at least a little credence to the worries of the experienced people.

> use the best tool for the job. For me, right now, that is Python 2.7.

Sorry, but these two statements seem at odd with each other. I absolutely agree with the first principle, and I agree that in many cases 2.7 is more than good enough; however, in nearly all cases I have encountered (and I have, a lot!) Python 3 is notably better, which means that it is not "the best tool for the job".

For all the complaints, Python 3 was incredibly conservative about making changes that would completely break existing code. String handling was basically the big shift, and if you were writing good code to begin with wasn't super hard for most problem domains to adjust to. Clearing up some cruft in the way the standard library was organized wasn't hard to deal with either. And there wasn't a lot of new syntax in 3.0/3.1 and quite a bit of it was backported into 2.6/2.7 to make the transition easier.

And then there was a bit of a moratorium on language changes in 3.x to give people time to catch up from their 2.x codebases.

The result of which is a lot of people who didn't think Python 3 was a big enough deal to be worth putting in the effort to migrate, when the 3.x series started releasing. And now many of them are finally noticing all the cool stuff that's in 3.x now (3.6 is about to release), and noticing that their favorite tools and libraries have switched from "we support 2 and 3" to "we're dropping support for 2", and realizing they didn't take advantage of all the time they had to port stuff, and are angry and feeling left out and trying to find complaints to level at Python 3 in the hope that enough people will agree and just magically end it, port all the new features back to Python 2, and let them keep going as-is.

When Arch switched from /usr/bin/python being python 2 to being python 3, buckets of python scripts failed. When downloading third-party python programs, the only way I know to know which version of python to use is to try one and when try the other when it complains about syntax errors.

With a perl-style "use" declaration, the runtime can immediately tell you when you're using the wrong version, or even, in principle, switch to the correct runtime if it's installed.

Hashbangs should refer to a version: e.g. "#!/usr/bin/env python2". Github shows approx. 3M results for "/usr/bin/env python", but less than 200k combined for version-specific hashbangs.

Of course, there will always be those who find problems with any change and they're normally the most vocal.

Personally, I've struggled with various unicode issues in my code over the last few years and python3 might have saved me from all that. Even so, for a long time python3 didn't seem to offer enough of an advantage to make the switch although I have ported some of my code across which was relatively easy.

The hardest thing for me is that python3 has banned implicit relative imports within packages. Unfortunately I've tended to mix modules and scripts freely in my projects (scientific simulations) and so I'll need to restructure to port some of my projects.

Here's a non-example: Ruby. It was quite possible and not even that difficult to write code that ran on both Ruby 1.8 and Ruby 1.9 that had correct behavior for both systems, despite all of the pain people noted about the transition with Unicode just trying to use vanilla 1.8 code on 1.9... but the transition from Python 2.7 to Python 3.0 required an all-or-nothing approach for the numerous changes which could not be "from __future__ import"ed in 2.7: Python 3.0 almost seemed to go out of its way to screw with developers, renaming "str" to "bytes" and "unicode" to "str" without providing any aliases which could be used across the different runtimes and simultaneously removing the u"" prefix syntax while remapping "" (so there was no cross-version way to even say "this represents text). Even later versions of Python still didn't try to help with exceptions: the syntax simply changed and the only way to write code that worked on both was to catch exceptions without a name and then dig into sys.exc_info() to pull the value as part of the except block.

Meanwhile, the Python developers handled the bootstrap horribly: they have been giving the finger to people for using Python 2 ever since they started working on Python 3, putting 2.7 in what was essentially an "emergency maintenance only" mode, causing the runtime to stagnate for five years while they marched from 3.0 (which was nearly unusable) to 3.5 (which was where Python 3 started to look reasonable) and there was very little library uptake; so it isn't like higher-level code could transition even if it wanted to: application developers were stuck waiting on libraries and library developers were stuck waiting on the language itself to become more reasonable, and in that five year gap many people just started jumping ship to entirely different languages--such as Go, Rust, Clojure, and Elixir--as it isn't like they really had a choice (as again: they were blocked on people who were blocked on other people).

  b1 = b'bytes'
  s = str(b1, 'utf-8')
  b2 = bytes(s, 'utf-8')

I think that if the teams had somehow managed to coordinate a more or less simultaneous release then much of that early momentum wouldn't have been lost.

Here's how Aaron Swartz (and probably others as well) thinks the transition to Python 3 should have happened: http://www.aaronsw.com/weblog/python3

On a big python project at work we only very recently have lost our last dependency on a Python2 library and it took some dedicated effort to track and replace these dependencies. And upgrading all of our own code to be Python3 compatible will be a whole other can of worms (even though we were careful to write our code in a forwards-compatible way using future imports etc.).

End applications did not want to upgrade because no third party libs were available.

Third party libs did not want to upgrade because no applications would use them anyway.

The correct way to handle such a transition is a proper bridge to import old libraries, then applications dare to upgrade without missing out on libraries which later leads to a bigger demand on third party libraries.

Another big reason is simply plain old stupid FUD.

So yes, things are rewritten. And things are upgraded. But at a glacier's pace.

2020 is coming soon -- in about three years. There's no way that companies will upgrade some of these systems to Python 3 during that time. Some things, sure -- but there's a lot of legacy code out there, and I don't see them spending the time and money to upgrade something that already works.

I'm a German writing web apps using Django, and I constantly got UnicodeDecodeErrors when mingling with older browsers, uploads from Windows users, copy-pasted content from word processors etc.

The problem isn't (only) whether Latin-1 has all the characters, it's what encoding gets thrown at your software.

Python 3 was a blessing for handling user-provided input.

Python 3.3 caught it back up to, and started to exceed, 2.7 on benchmarks. And the gap is only going to grow as the 3.x series improves and the 2.x series lies stagnant.