2.6 RC 1 is out

If you didn't already know it, 2.6 RC 1 was released two days ago. There's nothing big to report (and there shouldn't be of course!). In fact, the biggest change you may notice is the absence of a 3.0 RC alongside. This is due to the fact that we believe although 2.6 is almost rock solid, 3.0 definitely still needs some more TLC. We are still aiming for a 2.6 final on October 1st, but 3.0 has been pushed back to the 15th. (You can, of course, see the whole release schedule in PEP 361.) Please, please, please take the time to download it and test it with your project; now is when we want to know about grotesque bugs and incompatibilities!

Fun with 2to3

Recently, I've been working on 2to3 code refactoring tool. It's quite exciting really; how often does automatic editing of source code work?

2to3 is completely written in Python using the stdlib. The main steps in code translation are:

1. 2to3 is given a Python source file and a list of transformations (in units called fixers) to apply to it.


2. 2to3 generates a custom parse tree of the source based on a Python grammar that combines elements of 2.x and 3.x's syntax. It takes note of exact indentation and comment so it will be reproduced exactly later.


3. Each fixer has a pattern that describes the nodes it wants to match in the parse tree. The tree is traversed while asking each fixer if it matches the given node.


4. If the fixer's pattern matches the node, the fixer is ask to transform the code. The fixer can manipulate the parse tree directly.


5. A diff against the original source is printed to stdout and optionally written back to the file.

Over the past few weeks, I've written a couple of fixers. It's pretty intuitive once you get the hang of it, but writing good tests is very important because Python's flexible syntax produces many possibilities you fixer must deal with. I also refactored lib2to3, so plugging a different system of fixers is much easier for custom applications. I've also written some documentation on it's usage. I hope to start documenting the API and writing a guide for creating fixers soon, so other people can start making use of lib2to3.

On the Google Open Source Blog

It seems my testing project has made the Google Open Source Blog! Once again, I'd like to give a huge round of applause everyone who made it possible!

The third betas are out!

Last night, Barry released the third and final betas for Python 2.6 and 3.0. This release really saw a monumental effort from everyone. Tuesday was filled with coding, code reviews, and bug fixes, and we were able to close all 10 release blockers. It was looking very bright for a release yesterday morning. (Including the fantastic omen of a green Windows buildbot.) That didn't stop another release blocker from popping up hours before the release. However, we were able to get that one fixed due to some excellent debugging on the parts of Amaury Forgeot d'Arc, Antoine Pitrou, and Victor Stinner. Highlights:

• A more completed memoryview implementation. (Once again thanks to Antoine.


• I fixed up the symtable module and wrote unittests and docs for it. It should actually be functional now...


• The threading API was renamed once again. Now daemon, and name are properties of the Thread object. (That's the last time I'm doing threading renaming I assure you!)


• multiprocessing has gotten more stable.


• Guido donated the SRE bytecode validator he wrote for the App Engine.


• Many, many, many little bug fixes.

Of course, there's still lots of work to do before we can get to release candidates. Hours after the release we already have 11 release blockers. In the mean time, I strongly encourage you to download 2.6 and 3.0 and test them with your project. The bug tracker is still there: http://bugs.python.org

bzr vs. hg -- a different perspective

I'd say one of my favorite parts of F/OSS is the educational value I can get from it. There's much more practical programming knowledge in Python/import.c than in your average CS textbook.

My code curiosity recently turned to my favorite (D)VCSes, Mercurial, and Bazaar. (I've tried reading Subversion, but the C is just too much.) Much of the world (including me) likes to battle over their merits, but I'd like to talk about what I saw in the source. (Disclaimer: I do not claim to have an good knowledge of either project's design philosophy or why things were done the way they were.)

On the superficial side, Bazaar has a lot more code than Mercurial does: About 1 MB with 2.5 MB of tests for Mercurial and 6MB with 6 MB of tests for Bazaar. I'm not going to make anything of it, though, for fear of condemnation. Mercurial's non-capitalized class names also drive me a bit crazy...

Overall, Mercurial appears to be a much simpler system, true to the wisdom of "do one thing well". The one repository format is beautifully simple. Bazaar, on the other hand, has to have layers of abstraction in order to make access over many protocols and different repository, branch, and working tree formats possible. For this complexity, it gains much flexibility allowing it to be a hybrid distributed and central VCS. Bazaar's source code also has many more comments and docstrings. Mercurial's looks rather bare in comparison.

Bazaar and Mercurial both seem to implement dirstate the same way. They also both have C extensions targeted to speed themselves up.

In the end, the both work well and are a pleasure to use, so I'm not going to complain.

The Second betas are out!

Our release manager, Barry Warsaw, has just released (I prefer unleashed) Python 2.6 and 3.0 beta 2 in the big, wild world. Highlights (that I can recall) include:

• Installing on Mac for 3.0 is fixed.


• test_multiprocessing hangs have been fixed.


• gettext has gotten a different API.


• Tracebacks now display their causes and contexts. See exception chaining.


• Antoine Pitrou got commit access. Yeah!

Even now, the planned final release date in October looms, so we need lots of people to test their application and libraries with the beta release and file bug reports.

Learning Django

Quite honestly, I haven't done any web programming since I quit PHP. I do hear a lot of about all those Python web frameworks, so when I saw a link to the Django Book, I took the initiative and started reading. I haven't tried out any other frameworks, but my initial reaction is to love Django. It's obviously well designed around DRY and the Zen and very well documented. Django models are beautiful and makes SQL very painless.

Having worked through the examples in the book, I've started conceiving a larger project. I'd like to make my personal homepage. Obviously, it would have a lot of static content, and I want to do that in the clearest way possible. So, I'll steal a hint from the django docs: write my site in reST and dynamically generate the webpage with docutils. (It will be a good exercise with caching.) In fact, I have a version running locally.

[My first lazyweb query:] Where can I get good Python hosting? I'll need to upload Django, too because I'm running off SVN. Can it be gotten cheap or even for free?

BTW, I'm now aggregated on Planet Python!