If you ask Python creator Guido van Rossum, Python 3.0 -- which shipped last Friday -- is the best version yet. It's more consistent, it's more streamlined, and it does away with a lot of the cruft that had been lingering around since earlier iterations of the language.
It's also light on new features, it breaks backward compatibility so thoroughly that most old Python code will need to be rewritten to run on it, and it benchmarks about 10 percent slower than Python 2.5. But hey, you can't have everything.
Language designers have tried that before, van Rossum says, and it seldom works. "C++ became too complex for the average developer by having as an explicit goal backward compatibility (with C no less) and the ability to get as close to the hardware as possible," he writes in a recent blog post. Adding that kind of complexity to Python wouldn't be doing programmers any favors.
In fact, van Rossum and his collaborators put the greatest emphasis on taking things out of Python 3.0, rather than putting them in. What other major programming language can make that claim?
But then, Python has always been a little quirky. In a wry jab at Perl creator Larry Wall's famous mantra, "there's more than one way to do it," the Python community likes to say, "There should be one -- and preferably only one -- obvious way to do it." They're just joking. Kind of.
Spring cleaning at Chez Python
But if Python's Spartan philosophy seems quixotic, it has earned the language a dedicated following. Today Python runs on everything from mainframes to mobile phones, and the roster of its devotees includes such big names as AstraZeneca, Google, and Industrial Light and Magic. It powers all kinds of cutting-edge computing, from drug discovery to the Google App Engine.
Some measure of that success can be attributed to the fact that Python is free, open source, and community-developed. But the downside of community development is that the community inevitably has ideas. Sometimes those ideas blossom into valuable, lasting additions to the language. Other times, not so much.
That's why, for Version 3.0, the Python developers decided to clean house. Redundant features were removed, inconsistent syntax was cleaned up, and ideas past their prime were retired. And there was no pussy-footing around. When van Rossum says Python 3.0 is "the first ever intentionally backward incompatible Python release," he isn't kidding.
For example, Python 3.0 does away with the print keyword. Printing to the screen is now handled by a function -- as it is in C -- which means the syntax has changed. Nearly every quickie Python script ever written will need to have parentheses added to its print statements before it can run on the new interpreter.
The way the language handles text has changed, too. While older versions allowed programmers to mix strings of differing encoding types (with varying results), Python 3.0 enforces stricter division between the concepts of binary data and text data -- and text is always Unicode. Because of this, any code that deals with Unicode text the old way will need updating.
The list of changes goes on, but one thing is certain: These aren't fringe-use cases. Commonplace, standard, correct, functioning Python 2.5 code probably won't run under Python 3.0 without modification.
Slithering ever onward
Fortunately, the answer for most developers is simple: For now, just keep using an older version. Python is developed along multiple branches; the 3.0 branch doesn't automatically supersede the others. Python 2.6 was only released this past October, and a Python 2.7 is reportedly in the works.
In fact, most developers are still using version 2.5. But the advantage of the later releases is that they act as stepping stones to Python 3. No need to pore over those print statements yourself; if you're writing good Python 2.6 code, porting it to Python 3 can be as easy as running an automated conversion script.
And while the rest of the industry is just beginning the slow march toward Python 3, van Rossum and the other Python developers are still working -- fixing bugs, improving performance, and planning for the next version. As the Python Software Foundation's David Goodger explains, "We fixed problems so we can go forward and add features more easily in the future without having to work around previous bad decisions." And why not? For the Python community, it's the only obvious way to do it.