Tuesday, 31 December 2013

About Python 3: A response

This is a response to Alex Gaynor's blog post of similar subject line. I have to say, Alex's information is showing a very strong inherent bias toward Py2-binding. When scripts have minimal dependencies, it's really easy to switch them across, and it's often not hard to make a single codebase that will run on either Py2 or Py3.

On most Linux installations, the 'python' command will run Python 2, and Python 3 has to be called for explicitly with 'python3'. Yes, this may make it look like Py2 is the standard and Py3 is the upstart, and it means that a lot of code that's compatible with both versions will be running under Py2, both of which make it look like we're not using Py3 all that much yet. But that's just skewed stats, not reality. Alex claims that "almost no code is written for Python 3", and while that may be true in his own personal experience, it's definitely not true of the whole world.

Alex then makes two points, which I shall juxtapose. "Why aren't people using Python 3? ... lack of urgency" and "Here's an idea: let's release a Python 2.8". The problem here is that that's the exact attitude that creates the lack of urgency. Here's an alternative idea: Let's NOT release a Python 2.8, so that there really will be no new features in the 2.x line. And let's keep on releasing cool new features in 3.x (how about an async I/O package, support for enumerations, and a library of statistical functions, that's a good start), so there's a strong incentive to switch.

I do understand that it's hard to switch. For someone who's grown up thinking that a character is a byte and that ASCII is all we need, getting your head around Unicode and the need to distinguish what you work with from what you store/transmit does take some effort; but it's something you'd have to do anyway, the only difference is that Py2 lets you defer the distinction until you get a non-ASCII character but Py3 forces you to think about it up-front. Same goes for other changes - the Python 3 way is definitely better, or it wouldn't have been done; if anyone feels strongly enough that a change was wrong, then maybe a "from __past__ import" statement might be implemented. But I'd like to see a solid argument against any of the Py3 changes (I personally disagree with int/int -> float, since float is not a superset of int, but we have int//int -> int so it's just a matter of choosing the operator) - would make a great thread for python-list.

We live in a world, not a series of separate countries. It's high time we had Unicode by default - not "hey, look, this is a Unicode string over here, isn't it special", but "all text is Unicode, and we can also manipulate streams of bytes". Python 3 gives us that. It's high time Python 2 was treated as the legacy interpreter it is - all new code should be written with Py3 in mind. Yes, I understand that some people choose to support older versions of interpreters, for various reasons - I do it myself, in ways that sometimes warp my codebase somewhat - but that should be a conscious choice and not just "here's how to write Python code". Unicode 2.0 was released nearly two decades ago, so it's time to acknowledge that characters aren't bytes, and aren't 16-bit units either. Never mind about "bridg[ing] the gap" between Py2 and Py3 - leave the gap there, and jump over it.


Anonymous said...

"""how about an async I/O package, support for enumerations, and a library of statistical functions, that's a good start"""

Those are fairly wild ideas you're having here!

Chris Angelico said...

Yeah I know, weird combination too. But you know what they say... rule of three, or in this case rule of three point three!