Various notes, all about Python

Jeff Waugh recently brought back memories of that talk with a weblog entry on how Python behaves. For the curious: start up an interactive Python interpreter, then examine it from another window with strace. That Python interpreter, seemingly doing nothing, is, in fact, busily waking up ten times per second so that it can do nothing in a more active way. The offending code (in the readline library) is easy to find; it wakes up every 100ms just in case somebody might have registered a hook to look for events outside of the input file descriptor. As it turns out, the Python GTK library does the same thing so that it can check for pending signals.

So a system running a number of Python GTK applications (and some systems have many) will be experiencing the load of each one of them doing nothing every 100ms. This sort of behavior uses CPU time needlessly and it keeps the processor from sleeping - thus draining laptop batteries more quickly. Not good behavior - and a bit of low-hanging fruit that, one hopes will get fixed in the near future.

Meanwhile, the Python developers are working toward a major new release with the first Python 2.5 release candidate in testing for the last few weeks. For a full description of what's in Python 2.5, see A.M. Kuchling's excellent summary. New language features include conditional expressions (something like the "? :" notation used in C, but with a very different syntax), partial function application (forms of functions with some of the arguments supplied ahead of time), a number of exception handling improvements, a "with" statement intended to provide robust cleanup handling, and a number of performance improvements. There is also a long list of new modules and enhancements to existing modules.

The Python developers have long talked, often not entirely seriously, about "Python 3000," the upcoming major update to the language. While the Python language has evolved considerably over the 2.x series, it has done so in a compatible manner - older Python programs continue to run (though Python extensions written in other languages have tended to break). With Python 3000, the plan is that anything can happen, and there will be no guarantee (or even, perhaps, hope) that unmodified Python 2.x programs will work.

Python 3000 has been, as they say, Py in the sky for some time. But it looks like that situation might change before too long; some serious plans for the Python 3000 series have been laid down, and development may happen soon. Very soon, according to Python benevolent dictator for life Guido van Rossum:

He goes on to suggest that much of the work for Python 2.6 may be oriented toward helping programs (and programmers) make the jump to the eventual 3000 release. So Python 2.6 may not contain a whole lot of new features, but it could have a bunch of new warnings for things that will break in the future - and fixes to the standard modules to avoid those warnings.

The first alpha Python 3000 release is expected sometime next year; it could be a year or so after that before the stable release (to be Python 3.0) is ready. Current plans are to continue to develop and support 2.x for some time - well into the 3.x series.

What will be in Python 3000 3.0? Python Enhancement Proposal 3100 has the details, as they are understood at the moment. These include the removal of old-style classes, various expression syntax changes, a new set syntax, use of Unicode throughout (but no non-ASCII characters used in the language itself), and much more.

Python hackers who are concerned about changes to the language might want to take a look at PEP 3099, a document listing the things that will not change. These include no implicit self, no programmable syntax, no overly complex parser, and so on. There will be no braces added in Python 3.0, preserving the grouping by indentation that is such a strong characteristic of the language; for some amusement, fire up Python and type:

    from __future__ import braces

In the end, for all its changes, the Python language will still be very much true to its original goals: a straightforward language with one clear way to carry out most tasks. Python 3.0 will also be developed in an evolutionary manner - no massive rewrite or multi-year series of pronouncements from the language designer. As a result, Python 3.0 should, despite its rather later start, be in use well before Perl 6.

Finally, for a different and interesting project, PyPy is worth a look. These developers are writing an entirely new Python interpreter - in Python. There are a lot of goals driving this work, one of which is the ability to compile the interpreter into a runtime system which is highly targeted for its intended purpose. Different builds can use different memory management algorithms, for example. The developers believe that they will eventually be able to build Python systems which run faster than the current C interpreter - though, at this point, they are running about three times slower. It is an active project, however, which is making rapid progress; expect interesting things from that direction.