Python 3 is out - now what?

For some years now, the Python development community has been talking about "Python 3000," the far-future release which would allow a complete rethinking of the language to fix the various annoyances which had built up over time. On December 3, that talk came to fruition with the Python 3.0 release. This release is the end result of a great deal of thought and development; it represents the vision Guido van Rossum and company have for the language into the indefinite future. Now that it's out, the Python community as a whole appears to have stopped for a "now what?" moment.

The wider Python development community appears to be split into three camps on Python 3.0; the situation amusingly resembles the classic folk tale "Goldilocks and the three bears." One set (the "too large" crowd) seems to think that an incompatible version of Python should never have been released, that languages should stay compatible forever. Another group ("too small") can handle the idea of an incompatible transition, but thinks that the Python community should have added more shiny features to the language while they were at it. And, of course, there's a "just right" crowd taking the position that the changes in Python 3 are just about as they should be. See this discussion by James Bennett for a well-argued description of the "just right" position.

Time will tell which position is closest to reality. If the "too large" group is right, Python 3 (or Python in general) will fade away as developers, unhappy with the break, move to a language they like better. If Python 3 is too small, there will be strong pressure for a Python 4 in the too-near future. Your editor, though, thinks that the Python community has come pretty close to getting it right. Things that truly needed to be fixed got fixed, but the Python developers resisted the temptation to try to do too much. They watched, from a safe distance, what happened with the Mozilla rewrite and Perl 6, and wisely concluded that their lives - and the lives of those who use Python - would be better if they avoided a similar experience. So they limited their goals and were able to get the job done in a reasonable amount of time.

Except, of course, that the job is not really done. To begin with, the presence of a few difficulties with the 3.0 release should not surprise anybody. The developers forgot to remove the deprecated cmp() function, with the result that newly-converted code may come to depend on it. There are some performance issues. A couple of other features are not working quite right. Getting Unicode truly straightened out may take a while yet - a problem which is certainly not unique to Python. The list seems to be quite short given that this is a major release of a complex programming language, but there are still things to fix. So there will almost certainly be a 3.0.1 release before the end of the year, and a 3.0.2 in (approximately) February.

Meanwhile, the Python hackers have made it clear that the 2.x version of the language will be supported for some years yet. Version 2.6, available now, includes a number of features aimed at making the eventual port to 3.0 easier. As the porting projects get serious, other ways to help that process will become clear; there will be an eventual 2.7 release which incorporates those lessons wherever possible. A 2.8 release further down the road has not been ruled out. The current plan seems to be to maintain Python 2.x for at least the next three years.

[PULL QUOTE: For many Python developers, it is not yet really time to make the jump to 3.0. END QUOTE] That is good because, for many Python developers, it is not yet really time to make the jump to 3.0. The core language appears to be in reasonably good shape, but a language like Python involves much more than the core. Most non-trivial code makes heavy use of the wide variety of Python libraries, and, at this point, many or most of those libraries do not support Python 3. So, now is a good time for library maintainers to be looking at moving to 3.0, but application developers who try to port their code now are likely to run into frustration. Porting smaller programs or subsystems as an exercise in learning the new language may make sense, but complex application porting probably cannot happen for a little while yet.

What distributors should be doing is another question. So far, it would appear that only Fedora is having a (public) discussion on how to handle the Python 3 transition - see this thread - and they don't really know what they are going to do yet. Fedora's maintainers, it seems, would prefer to stay with Python 2 for the indefinite future; the chances of Python 3 making an appearance in Fedora 11 are quite small. There is a strong wish to avoid maintaining both 2.x and 3.x on the same distribution release; they would rather make a clean switch.

Your editor suspects that the flag-day approach to the language transition is not going to work. There are a lot of packages which need to be ported, and many of the people doing the porting would appreciate support from their distributor. Red Hat dragged its feet for a long time on the transition to Python 2, with the result that many users had to build and install the newer version of the language themselves. For Fedora to do the same with Python 3 is a sure path toward user frustration.

That said, keeping both versions of the language around is not a task for the faint of heart. Installing a different version of Python itself is quite easy. Keeping a whole set of modules for multiple versions is distinctly less so. This will be especially true for Fedora; some other distributions (especially the Debian-derived ones) have better mechanisms for (and experience in) maintaining multiple versions of core system tools. So the reluctance on the part of the Fedora developers to take on this work is thus unsurprising. Perhaps this would be a good opportunity for offers of help from the wider Fedora community.

It may well take a couple of years, but this transition will eventually be made and people will eventually wonder what all the fuss was about. And, when it's done, we'll have a cleaner, more maintainable, more Unicode-rational version of an important programming language to work with. That, one hopes, will be worth the short-term pain involved in getting there.

(For more information, see the Python3000 FAQ, currently under development).

---

to post comments