A lot of the recent discussion around python3 has been about how 2to3 is slow and inconvenient, so this seems like a good time to plug my attempt to improve the process. https://github.com/bdarnell/auto2to3 uses an import hook to run 2to3 on changed files automatically, and cache the results on disk between runs so it doesn't have to run 2to3 over the entire project every time (and the caches are ordinary files so you can see exactly what 2to3 is producing).
This is how I added Python 3 support to Tornado. If you intend to keep supporting Python 2.5, I definitely recommend using 2to3 instead of the contortions required to use a single codebase across all versions (if you're only supporting 2.6+ it gets much easier to do everything in one codebase without 2to3, although even then 2to3 can help keep the primary (2.x) codebase cleaner).
The entire concept of 2to3, however, was stupid... what you need is 3to2. You want to be encouraging people to write new code, and support old versions as best as possible, not write old code and support new versions as best as possible. 2to3 should be used as a one-off migration tool, but it is seriously suggested to use it as part of people's builds.
In the long term I think we need both 2to3 and 3to2, but for now 2to3 is more important. As long as both my dependencies and the users of my library are mostly on 2.x, I want that to be my primary development platform. If the only way to support both platforms was to do most of my work in python 3 and then backport to 2.x, I'd have never gotten started because that's too much of a change to take on at once. 2to3 gives me a way to support 3.x now (even as a second class citizen), and then a path to flip things around and make 3.x the primary platform when I'm ready.
I just find the "for now" pretty hilarious: we are already seeing a shipping version of Python 3.2, with Python 3.x having been released for years, and we still need to encourage people to develop code for Python 2.x and use a build step to convert their code to Python 3.x. The effect of this attitude directly contributes to the behavior described in that recent article by the Jinja2 developer: where Python 3.x support is often considered by people to be just "look, I did it, and while it is a horrible hack and much slower than the 2.x version, it sort of works; now leave me alone", as opposed to helping people slowly embrace Python 3.x.
I was just thinking of mocking up something like this...so why don't you write us up a blog post about this and get a little publicity ? If we could add on an "auto2to3" as easily as we build a virtualenv this has the potential to neutralize the "it's too hard to wait for 2to3" complaint.
This is how I added Python 3 support to Tornado. If you intend to keep supporting Python 2.5, I definitely recommend using 2to3 instead of the contortions required to use a single codebase across all versions (if you're only supporting 2.6+ it gets much easier to do everything in one codebase without 2to3, although even then 2to3 can help keep the primary (2.x) codebase cleaner).