Pensieri di un lunatico minore

The Python 3.0 kerfuffle

Seriously, did someone put something in the water and cause people to simply lose their freaking minds? There are posts all over the bloggotubes of people with righteous indignation about their persecution by Guido, or something like that. I don’t know, it’s hard to see the point through the hand waving. A few observations are in order.

First, this is not a surprise. Python 3000 has been under consideration and development for 8 years. Eight years. There are no surprises to anyone who has been paying attention to the development process. The alpha code was released publicly over 15 months ago. There has been a steady stream of alphas, betas and release candidates during that time. During that time, there has been ample discussion of the changes that were coming, and more importantly, the rationale behind every single one.

Next, the 2.x family of Python is not being abandoned. This was made very clear by everyone involved. There will continue to be regular relases, and 2.7 is already under way. No doubt there will be a 2.6.1 and perhaps even a 2.6.2. There likely will even be a 2.8 at some point. The point is that new features are not going to be developed in the 2.x branch of code. They may be back-ported, where it makes sense, but they will not originate there any more.

It is important to never forget the Zen of Python, as channeled by the inscruitible Tim:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one—and preferably only one—obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea—let’s do more of those!

Python 3000 (or just Python3) was all about hewing closer to the Zen of Python. As Guido’s time machine has been on the fritz for the past few years—I suspect it’s been impounded by Google—it was necessary to actually fix these in the future, rather than retroactively fixing the past. Most especially, the focus was on TOOWTDI.

So what does that mean for the teaming hoards that are attempting to overrun the castle? It means to back off, and understand that it isn’t expected, or even intended that you migrate to Python 3.0 right now. So why release? Because if you don’t release, it’ll never happen. Now is better than never.

What I’ve started doing is:

• Run the 2to3 tool over my code to figure out what, if anything, will have to change. A huge number of the thousands of scripts I’ve written over the years don’t require any manual changes.
• Mark my code with comments about what will need to be changed at some point with things like

  # PY3K

  where the changes can’t be automated by 2to3.
• Compile a list of all the libraries I depend on and start tracking them more closely to see where they stand in compatibility. This includes running 2to3 over them to see how bad it might be.

I considered trying to write to the intersection between Python 2.6 and Python 3.0, but the absurdity of that was obvious after 5 minutes.

Overall, yes, it’s a shift, but it’s not that big a shift. People are over-reacting. The single biggest impediment is actually the C-level APIs changing. This needed to happen, as they’d gotten very krufty in the passing years. It will, however, necessitate a lot of code getting updated, and, as far as I know, there’s no automated tool to fix it up like 2to3 can for Python code.

Short term pain? Yes. Long term benefit? Most definitely. In the meantime, it’s trivial to keep both 2.6 and 3.0 installed on the same system. And for those who pout that #!/bin/env python isn’t an adequate first line: it never was. It never expressed the version dependencies that were likely there, if not in the language, in the installed libraries. Python has, for as long as I can recall, installed a version-specific interpreter, so use #!/bin/env python2.6 if you care which version gets run.