What's new, what's planned and why people need to calm down about the division operator.
With version 2.2 [and now 2.2.1] finally released to the world, we took some time to ask Guido van Rossum, Python's inventor and PythonLab's director, to share some of his thoughts about the latest Python news.
Wesley Guido, thanks for taking the time today to talk with us at Linux Journal.
Guido It's always a pleasure to work with LJ.
Wesley Give us one or two sentences of overview about the new 2.2 releases.
Guido The release of 2.2 is the first step on the way to a new object model for Python, where built-in classes and user-defined classes finally have equal footing. In addition, there's cool stuff, particularly generators.
Wesley Why should current developers migrate from Python 2.0.x or 2.1.x to 2.2.x?
Guido To benefit from the new style class features, such as properties, static methods and subclassing list and dict, or for generators.
Wesley Why should current developers migrate from Python 1.x to 2.2.x?
Guido In addition to the features already mentioned, to benefit from the tons of bugs that were fixed and the features added in 2.0, such as list comprehensions, Unicode, XML and a new regular expression implementation. If you're happy using 1.5.2, be my guest. If there's anything in 1.5.2 that irks you, there's a good chance it's been fixed in 2.x.
Wesley Some developers have never seen iterators or generators before. Where did they come from, and why were they added to Python?
Guido C++ has iterators, and they are actually a pretty common programming pattern, just not usually a language feature. But in an interpreted language like Python, the boundary between the language and the library is often blurred. Generators come from a little-known language called Icon, but they deserve to be in the spotlight; they are an incredibly powerful way to write more readable code for certain situations. You can also see them as a tamed form of co-routines, an old idea (described, for example, by Knuth) that unfortunately went out of style because it required stack fiddling.
Wesley In many other object-oriented languages, classes are seen as types and their instances as objects of those types. Why was this not the case for Python and why the turnaround?
Guido That was an implementation artifact. The very first version of Python (which was never released, but used internally at CWI in early 1990) didn't have a class statement; the only way to add a new data type to a program was to write an extension in C. Someone suggested that I add classes so that end users also could define new data types. I invented an implementation that required minimal changes to the abstract Python virtual machine. But the class statement couldn't do exactly the same things as the C programmer could.I've known for a long time that this needed to be fixed, but solving it required a large implementation effort for which I didn't have the time earlier on—in part because during the intervening ten years the language had become so successful that I just couldn't change the rules. I had to make sure that old code continued to work unchanged, and I had to provide a migration path to using the new features. I think I've succeeded at both.
Wesley The changing of the division operator has been the source of much controversy and debate. What are you telling each side to keep flame wars to a minimum?
Guido The folks who want the new division operator don't need to be told to keep flame wars at a minimal level—it's the people who mistakenly fear that all their code will break overnight who need to be calmed down. It's the same issue as with the new style classes: 99% of the implementation effort went into finding ways to implement it without breaking old code. No code using / for int division will have to be changed until Python 3.0, which is several years off.In the meantime, folks can choose on a per-module basis to use / for float division. I'm also supplying two tools (finddiv.py and fixdiv.py) that can be used to track down and fix / operators that would need to be changed to // in order to work properly in Python 3.0. We've already converted the entire standard library to using // where necessary. It's not a particularly hard task, but it can't be 100% automated because it's impossible to tell for sure at compile time what the operand types are.By the way, a change to integer semantics that is nearly universally liked is the automatic conversion to the long type when any operation on ints would raise an OverflowError.
Wesley Any new developments for those who write Python extensions?
Guido Yes, they can create types that are subclasses of standard types, and they can create types that are subclassable. There's a bunch of new slots in the type object that extension authors can use to fine-tune what happens when an object of their type is created or destroyed.
Wesley Python 2.2 brings a good number of new and improved modules. What are your top ten updates to the Python Standard Library?
Guido Surprisingly, I'm not usually on the bleeding edge of the library, so I can't quite make it to ten. First of all, there's the new e-mail package by Mailman author Barry Warsaw. There's the hot-shot profiler by my colleague Fred Drake, the XML-RPC support by Fredrik Lundh and, last but not least, the IPv6 support, a coproduction of Jun-ichiro “itojun” Hagino and Martin von Loewis. I think Python's IPv6 support is way ahead of other languages.
Wesley Are the new features of 2.2 going to be included in Jython, the Java language Python interpreter?
Guido Yes, the Jython developers have been active on the python-dev mailing list to be sure that we wouldn't add features that were unimplementable in 100% pure Java. This is one of the reasons why generator functions require the use of a new keyword—Jython needs to know that something is a generator at compile time. They released their final Jython 2.1 soon after we released Python 2.1, so I expect that they are working on Jython 2.2. The type-class unification work should be easier in Jython than it was in the C implementation of Python, because they were already basing both built-in types and user-defined classes on Java classes.
Wesley Jython 2.1 was released soon after Python 2.2. What version of Python is it most compatible with? In other words, how far behind is Jython?
Guido The Jython version numbers match the Python version numbers, so Jython 2.1 is compatible with Python 2.1.
Wesley What can we look forward to in Python 2.3? Any timeline for that release?
Guido I expect 2.3 to be a release of consolidation and performance tweaks, not of grand new features like 2.2 was. We may also focus more on the standard library than on changes to the core language. There's now a schedule for 2.3; see PEP 283 for tentative future release dates. I like doing a new release every six months, as we've done since 2.0.We are already done with 2.2.1, which is a pure bug-fix release for 2.2, as 2.1.2 is a pure bug-fix release (the last one, I'm sure) for 2.1. This is important because a lot of third-party code is out there (Zope 2.5 for example) that depends on 2.1 and cannot be migrated to 2.2 right away.
Editor's note: look for Wesley's article in next month's LJ for further details on the advancements of Python 2.2.
