It may just be anecdotal at this point, but several highprofiles libraries have given up on 2to3 entirely and use the 2/3 common codebase approach: Jinja, django, ply. For a library, that's the approach that I find more practical.
I have a hard time seeing how one can use 2to3 on an everyday basis: it makes testing, distribution, etc... that much more painful because it is so slow (2to3 takes as much time as compiling all the C code from numpy, for example). It also removes one of the big plus of a language like python (modify code - see the result right away).
Amen, 2to3 in practice for anything but the smallest library is effectively unusable due to speed. Even if it weren't, I'm not much of a fan of maintaining generated code. That's an imposition I'm not really willing to put up with.
Comments
It may just be anecdotal at this point, but several highprofiles libraries have given up on 2to3 entirely and use the 2/3 common codebase approach: Jinja, django, ply. For a library, that's the approach that I find more practical.
I have a hard time seeing how one can use 2to3 on an everyday basis: it makes testing, distribution, etc... that much more painful because it is so slow (2to3 takes as much time as compiling all the C code from numpy, for example). It also removes one of the big plus of a language like python (modify code - see the result right away).
Amen, 2to3 in practice for anything but the smallest library is effectively unusable due to speed. Even if it weren't, I'm not much of a fan of maintaining generated code. That's an imposition I'm not really willing to put up with.
Using a Jenkins server with continuous integration makes Py3K testing pretty painless.
I really don't want projects to go back to maintaining two source trees, that was a disaster.