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.
