After finishing the project for the Google Summer of Code 2009, I have made the first alpha release. You can get a gzipped tarball at http://bitbucket.org/amentajo/lib3to2/downloads/3to2_0.1-alpha1.tar.gz. Please file bug reports at http://bitbucket.org/amentajo/lib3to2/issues/. A Mercurial branch has been made for a snapshot of this release at http://bitbucket.org/amentajo/3to2-01-alpha-1/. The code is in basically the same state that it was in on the last day of the Summer of Code, except I have made fix_imports and fix_imports2 explicit-only. These two fixes were rather rushed, have inadequate test cases, are particularly fragile, and are known not to work properly with some imports in suites. They will, however, perform their basic function for the simple case of imports at the top of the module, no levels of indentation in. Another shortfall for fix_imports2, in particular, is that if a name is invoked from a module that is new to the py3k branch, the module name will be called “None” in the refactored code.
With the exception of those two fixers, everything should work relatively smoothly. The print fixer still just does “from __future__ import print_function”. The best thing that could happen for the project at this point would be for people to start using it on their actual 3.x code and manually verifying the results. I would love to hear via comments / e-mails the results of people actually using the program, whether they be good / bad / ugly (but especially ugly). I will gladly accept samples of code that do not translate as expected via e-mail, if you do not wish to go through the process of filing a bug report. These samples will help speed along the next release.
Note that 3to2 must be run with python2.7, as the version of 2to3 that comes with python2.6 is not recent enough.
WordPress has been updated to 2.8.4, securing it from the vulnerability discovered yesterday that permits the admin password to be reset by passing an empty array as the key parameter to a reset request:
http://www.startcodon.com/wordpress/wp-login.php?action=rp&key[]=.
This will fail now 
It’s time now for “what not to do if you want 3to2 to work”. The following is a list of things to avoid if you want 3to2 to work on your code (I’ll try to keep this up-to-date):
(Pay particular attention to imports if you import names referenced in PEP 3108)
- Incorrect syntax — If a Py3k interpreter fails on part of your code, don’t expect 3to2 to know what to do. Much of 3to2 is already picky enough without running it on things that simply don’t work in the first place.
- Third-party module references — If it doesn’t ship with Python, 3to2 won’t touch it. The intention is for 3to2 to do an adequate job automatically refactoring those modules so that the distributor will ship a 2.x version more easily.
- some_name = print; some_name(some_stuff) — Though technically this works for now, when the print function syntax is actually converted, it will not work.
- import [metamod] (For example, import urllib.request) — A work in progress, name-imports of modules made up of multiple 2.x modules merged into one in the 2->3 gap will not work. Use (from metamod import [names]) for now. The support for this one is getting better, but the bugs are still being worked out. Currently, you are golden if you only import at the top-level namespace of a module and always use at least one name from each module you import in this way. Also note that imports of this type that are never referenced with an attribute later are automatically deleted. Another “bug” with this is that if a module is imported, then an attribute of that module is referenced for which there never was a 2.x version, the name of that module after 3to2 becomes None without warning. This is visible at least in urllib.parse, which has some bytes references.
- import [metamod] as [name] — This will probably not work for a while, as the code is independently scanned for references to “metamods”, so please avoid using this form of imports.
- from [meta] import [mod] as [some_name] (For example, from dbm import gnu as zombie) — The underlying 2to3 code for (from meta import mod) disallows matching (as some_name), possible fix in the future. For now, refactor your code not to have that “as some_name”
- Any feature from the Py3k branch that has no syntactical equivalent in Python 2.x — 3to2 is here to refactor your syntax, not add features to Python 2.x. Warnings are in place for if your syntax is only valid in 2.6 or greater.
- Docstrings at the beginning of modules — If a future_stmt needs to be added, it is added before the docstring. This will be fixed, but be wary of it for now.
- Encodings that do not work for 2to3 — I’m not sure what these encodings are, but if you are having problems with it, please use chars valid in ascii only for now, until I can figure out if this is something that can be fixed. If anyone has any information that might be helpful, please comment or e-mail. More information on this: Even though py3k is more Unicode-friendly, 3to2 runs in python 2.x, so expect errors if you use an encoding that didn’t work in python 2.x. Even a character in a comment is not safe from crashing the parser. (See py3k/Lib/getopt.py)
- import [module] as [something_else] — This will probably never be fixed; 2to3 imposes this rule, so I will do the same for 3to2. (This is incorrect, please ignore.)
- from [metamod] import * (For example, from urllib.request import *) — Soon to be working, 3to2 will not succeed on imports of this type from a module that is made up of multiple 2.x modules merged into one. Use (from [metamod] import [names]) for now. This syntax will work now, but be careful about name conflicts related to having all the extra names in the namespace from importing * from all modules that the “metamod” depends on.
- from [module] import (names, more names, more names, some more names) — Status unknown, this failed for me. Use the line-continuation character \ at the end of lines of this type. This bug has been fixed.
Also, note that the status of fix_imports is “incomplete”.
It occurred to me this evening that fix_division.py has been in the lib3to2/fixes folder for a good, long time. I am so glad I didn’t completely overlook one of the “major” backwards-incompatible changes, only to remember it while musing about an unrelated topic.
Also, we have always been at war with Eastasia.