On Tue, Jan 5, 2010 at 10:10, Juan Fernando Herrera J. <juanfhj@gmail.com> wrote:
How about a new python 3 release with (possibly partial) backwards compatibility with 2.6? I'm a big 3 fan, but I'm dismayed at the way major software hasn't been ported to it. I'm eager to use 3, but paradoxically, the 3 release makes me rather stuck with 2.6. Excuse me if this has been suggested in the past.

The proper route to take, in my opinion, is to see what 2.x libraries you are using that are not 3.x compatible, run 2to3 on them, then run their test suite, and see where you get. Submit a patch or two to the library and see what happens -- it at least gets the wheels in motion.

It's not even that easy -- libraries can't apply patches for Python 3 compatibility as they usually break Python 2 compatibility. Potentially libraries could apply patches that make a codebase 2to3 ready, but from what I've seen that's more black magic than straight forward updating, as such patches have to trick 2to3 producing the output that is desired.

The only workable workflow I've seen people propose for maintaining a single codebase with compatibility across both 2 and 3 is to use such tricks, with aliases to suppress some 2to3 updates when they are inappropriate, so that you can run 2to3 on install and have a single canonical Python 2 source. Python 2.7 won't help much (even though it is trying) as the introduction of non-ambiguous constructions like b"" aren't compatible with previous versions of Python and so can't be used in many libraries (support at least back to Python 2.5 is the norm for most libraries, I think).

Also, running 2to3 on installation is kind of annoying, as you get source that isn't itself the canonical source, so to fix bugs you have to look at the installed source and trace it back to the bug in the original source.

I suspect a reasonable workflow might be possible with hg and maybe patch queues, but I don't feel familiar enough with those tools to map that out.