Python 3

[Robert Collins]

2to3 is indeterministic in the sense that users will have different
versions of it, with different capabilities.

I think 2to3 is a fine tool for small projects with no serious quirks,
but we aren't one of those. I enumerated all the issues I see with
2to3 earlier in the thread, so I won't repeat that now; but I think
that they need to be addressed before we can consider using 2to3 for
anything other than mechanical translation. Fixing things that are
outside of what 2to3 can do is likely a good idea anyway.

For the bytes stuff I've mentioned - see
http://bugs.python.org/issue5425 - 2to3 converts str to 'string' not
'bytes', so we have to mark up everything, and only Python 2.6
supports b'foo'. If we change the importer to go to bytes for 'str',
then we end up with all our literals that are meant for humans as
bytes, which is also wrong. And while we support < 2.6, we can't
annotate strings properly for bytes recognition without something like
a domain specific language - e.g. a _b() function.

We're a library, with very different concerns about when we stop
supporting a version of Python to a simple end user application that
doesn't care about embedding or reuse - and typically ships an entire
Python stack anyway. AFAICT 2to3 is *entirely* driven by 'hey, you can
*switch* over easily', not by ongoing maintenance concerns; the 'add
2to3 as a compile step in your application' is deeply unsatisfying

http://www.slideshare.net/regebro/python-3-compatibility-pycon-2009
and http://wiki.python.org/moin/PortingDjangoTo3k are interesting
reads and had some hand in shaping my opinion on this. Note that the
latter is a patch - you can get an impression of how much stuff 2to3
*didn't* do there.

-Rob