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.
I think that the ideas and tips of the article are useful, but I don't like the opening phrase.
People make mistakes. Once a mistake is part of a language specification the only way to solve it is to make a backward incompatible change. It's pain in the ass for the users, so you must not change this kind of changes too often if you like to have users.
A possible alternative is to have a huge metaprograming platform like Racket, that can still run the old version "mzscheme" programs almost unchanged [1]. But in the Racket/Scheme/Lisp word everyone is running their own slightly "improved" version of the language. So multiple languages are more natural than in Python with the " There should be one-- and preferably only one --obvious way to do it." philosophy.
(For example, they changed allowed syntax of "if".)
It does fail to mention that you need to also use special exception handling in all cases, eg.
try:
...
except TypeError:
e = exception()
...
...but it hits all the other things, except the obvious, make sure your tests are running continuously using py2, py3 and pypy, otherwise you'll just frustrate yourself as you're coding.
That exception handling is only necessary if you need to support 2.5 or older. A lot of projects now are just supporting 2.6 and newer, in which case you can use the Python 3 syntax:
Call me crazy but I would have renamed Python3 to a new name, i.e. Snake. That would have made it crystal clear that it's not the same language.
Seriously, Python3 made me hate python.
A couple examples why:
- The fact that I was using Archlinux and they decided to make "default python" -> "python3" = Hours of wasted efforts figuring which scripts weren't working.
- Every time I tried to go with 3.x = Screwed because libraries I needed weren't ported
- print 'x' not working = Just plain annoying
Let's make a new python4 == python2.7 and forget about all this python3 bullshit.
I seriously hope you're trolling. Yes, the transition is harsh, but it's getting better. On your points
1) that's a problem with Archlinux then, not Python. It was dumb to set 3 as default that sound
2) `3to2` works pretty nice for porting code
3) So you have to put parenthesis because it's now a real function. That's so bad. Also you can do stuff like `map(print, myiterable)` which you could not before, what a pain!
I really love Python, it is my language of choice, bread and butter, and I've been using it since 2005. However, this backwards compatibility break is probably the worst thing that happened to the language, as I think it's creating more project stalling and work in total than is worth any improvements specifically stemming from backwards incompatible changes. It could be because python3 still has not become my target, but that's kind of the point. When is it ever going to be?
What benefits does upgrading from python 2.x to 3 have? Why would you undertake that task? I don't understand why, unless python 3 offers some extremely compelling feature, or you are one of the small percentage of developers who delivers importable python libraries as your main developmental output.
[+] [-] zzzeek|12 years ago|reply
> 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.
[+] [-] avdd_|12 years ago|reply
> 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.
[+] [-] gus_massa|12 years ago|reply
People make mistakes. Once a mistake is part of a language specification the only way to solve it is to make a backward incompatible change. It's pain in the ass for the users, so you must not change this kind of changes too often if you like to have users.
A possible alternative is to have a huge metaprograming platform like Racket, that can still run the old version "mzscheme" programs almost unchanged [1]. But in the Racket/Scheme/Lisp word everyone is running their own slightly "improved" version of the language. So multiple languages are more natural than in Python with the " There should be one-- and preferably only one --obvious way to do it." philosophy.
(For example, they changed allowed syntax of "if".)
[+] [-] shadowmint|12 years ago|reply
It does fail to mention that you need to also use special exception handling in all cases, eg.
...but it hits all the other things, except the obvious, make sure your tests are running continuously using py2, py3 and pypy, otherwise you'll just frustrate yourself as you're coding.[+] [-] takluyver|12 years ago|reply
[+] [-] YellowRex|12 years ago|reply
[+] [-] d0m|12 years ago|reply
Seriously, Python3 made me hate python. A couple examples why:
Let's make a new python4 == python2.7 and forget about all this python3 bullshit.[+] [-] bru|12 years ago|reply
1) that's a problem with Archlinux then, not Python. It was dumb to set 3 as default that sound
2) `3to2` works pretty nice for porting code
3) So you have to put parenthesis because it's now a real function. That's so bad. Also you can do stuff like `map(print, myiterable)` which you could not before, what a pain!
[+] [-] Demiurge|12 years ago|reply
[+] [-] tshepang|12 years ago|reply
[+] [-] oh_sigh|12 years ago|reply
[+] [-] zdw|12 years ago|reply
Or is this a case where 2.6 needs to be supported?
[+] [-] mortdeus|12 years ago|reply