this article takes awhile to get to the point, but the point is correct which is:
> In other words, this is how it should be, that you write your code once, and you can use any supported language version to run it/compile it, or develop in. But for some reason, this obvious solution has been discouraged by Guido and other Python documents, as seen above. I just looked up the latest official Python docs, and that one is not upfront negative about a single code base. But it still does not recommend this approach as the one. So let me fix that: I do recommend a single code base as the solution.
2to3 is definitely useful to do the initial conversion of a codebase from something totally 2.x into one that is 3.x compatible. But from that point on, you need to put it away and not look at it again. Now that it's socially acceptable to target 2.6 at the lowest, libraries that wish to target 2.6-3.x still need to have a little bit of conversion code present, i.e. a subset of six, but other than that the code can be fairly py3k-ish.
Armin's article here is the most up to date discussion of this: http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ (though lots of us disagree with his decision to dump 3.1/3.2). This article has lots of great advice like "test for py2k not 3k" as well as his metaclass decorator that is a lot nicer than six's. SQLAlchemy's second py3k port (yes, due to the original advice we all have had to port to python 3 twice) makes heavy use of these techniques.
At this point I have all of my major codebases supporting 2.x-3.x. Particularly, Mako templates supports python 2.4 all the way through 3.x with no conversion - and Mako deals heavily with unicode and Python AST structures.
So hopefully the Python docs can catch up with the reality soon. The original advice to think very separately about your 2.x and 3.x codebases was very wrong, has wasted a ton of time (since you end up porting to python 3 twice), and overall slowed down the adoption of py3k, a slowdown that fortunately is finally lifting.
> I'll start with the conclusion: making backwards incompatible version of a language is a terrible idea, and it was bad a mistake.
> So let me fix that: I do recommend a single code base as the solution.
> The original advice to think very separately about your 2.x and 3.x codebases was very wrong, has wasted a ton of time (since you end up porting to python 3 twice), and overall slowed down the adoption of py3k, a slowdown that fortunately is finally lifting.
Is this opinion common? Do Guido and the other core developers admit they were wrong?
> Python 3.0 will break backwards compatibility. Totally. We're not even aiming for a specific common subset.
That a single code base is now possible, albeit "not entirely idiomatic", does support the conclusion that the original aim to break compatibility was misguided at best, and raises questions about the governance of Python overall.
If 'raises questions about governance' means the leadership can't predict the future, then I agree. Else, this is not fair, since features were added to Python 2.6 to reduce migration pain (which incidentally enabled this single-codebase thing possible).
> In other words, this is how it should be, that you write your code once, and you can use any supported language version to run it/compile it, or develop in. But for some reason, this obvious solution has been discouraged by Guido and other Python documents, as seen above. I just looked up the latest official Python docs, and that one is not upfront negative about a single code base. But it still does not recommend this approach as the one. So let me fix that: I do recommend a single code base as the solution.
2to3 is definitely useful to do the initial conversion of a codebase from something totally 2.x into one that is 3.x compatible. But from that point on, you need to put it away and not look at it again. Now that it's socially acceptable to target 2.6 at the lowest, libraries that wish to target 2.6-3.x still need to have a little bit of conversion code present, i.e. a subset of six, but other than that the code can be fairly py3k-ish.
Armin's article here is the most up to date discussion of this: http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ (though lots of us disagree with his decision to dump 3.1/3.2). This article has lots of great advice like "test for py2k not 3k" as well as his metaclass decorator that is a lot nicer than six's. SQLAlchemy's second py3k port (yes, due to the original advice we all have had to port to python 3 twice) makes heavy use of these techniques.
At this point I have all of my major codebases supporting 2.x-3.x. Particularly, Mako templates supports python 2.4 all the way through 3.x with no conversion - and Mako deals heavily with unicode and Python AST structures.
So hopefully the Python docs can catch up with the reality soon. The original advice to think very separately about your 2.x and 3.x codebases was very wrong, has wasted a ton of time (since you end up porting to python 3 twice), and overall slowed down the adoption of py3k, a slowdown that fortunately is finally lifting.