Is Python 3.0 the Holy Grail?

The Python Software Foundation released Python 3.0, the latest version of the Python language, on Dec. 3.

Python 3.0, also known as Python 3000 or Py3k, is a new version of the language that is incompatible with the 2.x line of releases, Python Software Foundation officials said.

According to the PSF, with Version 3.0 the Python language is mostly the same, but many details, especially how built-in objects such as dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places, foundation officials said.

In response to a query from eWEEK, Guido van Rossum, the creator of the Python language, said the standout features in Python 3.0 are, "Much better Unicode support, and cleanup of collected 'cruft.'"

In a Dec. 4 blog post about Python 3.0, Van Rossum said:

Compared to 2.6, Python 3.0 is the first-ever intentionally backwards-incompatible Python release. There are more changes than in a typical release, and more that are important for all Python users. Nevertheless, after digesting the changes, you'll find that Python really hasn't changed all that much—by and large, we're mostly fixing well-known annoyances and warts, and removing a lot of old cruft.

Indeed, "Python 3.0 uses the concepts of text and [binary] data instead of Unicode strings and 8-bit strings," Van Rossum said. "All text is Unicode; however, encoded Unicode is represented as binary data ... As a consequence of this change in philosophy, pretty much all code that uses Unicode, encodings or binary data most likely has to change. The change is for the better, as in the 2.x world there were numerous bugs having to do with mixing encoded and unencoded text."

In a blog post from March, Van Rossum warned Python developers: "Don't change your APIs incompatibly when porting to Py3k."

He added:

Yes, you heard that right: even though Python 3.0 is changing incompatibly, I implore you (especially if you're maintaining a library that's used by others) not to make incompatible changes to your API. If you have make API changes, do them before you port to 3.0—release a version with the new API for Python 2.5, or 2.6 if you must. (Or do it later, after you've released a port to 3.0 without adding new features.)

Explaining a bit further, Van Rossum said, "Why? Think of your users. Suppose Ima Lumberjack has implemented a Web 2.0 app for managing his sawmill. Ima is a happy user of your most excellent Web 2.0 framework. Now Ima wants to upgrade his app to Py3k. He waits until you have ported your framework to Py3k. He does everything by the books, runs his source code through the 2to3 tool, and starts testing. Imagine his despair when the tests fail: How is he going to tell whether the breakage is due to your API changes or due to his own code not being Py3k-ready?"

Yet, "On the other hand, if [you] port your Web 2.0 framework to Py3k without making API changes, Ima's task is much more focused: The bugs he is left with after running 2to3 are definitely in his own code, which (presumably) he knows how to debug and fix," Van Rossum said.

Incidentally, despite the fact that many believe the language's name, Python, is derived from the snake by the same name, it is not. The Python language is so named in homage to the "Monty Python" comic team.

According to a Wikipedia entry on the subject: "An important goal of the Python developers is making Python fun to use. This is reflected in the origin of the name (based on the television series "Monty Python's Flying Circus"), in the common practice of using Monty Python references in example code, and in an occasionally playful approach to tutorials and reference materials. For example, the metasyntactic variables often used in Python literature are spam and eggs, instead of the traditional foo and bar."