this article takes awhile to get to the point, but the point is correct which is:<p>> 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.<p>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.<p>Armin's article here is the most up to date discussion of this: <a href="http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/" rel="nofollow">http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/</a> (though lots of us disagree with his decision to dump 3.1/3.2). This article has lots of <i>great</i> 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 <i>twice</i>) makes heavy use of these techniques.<p>At this point I have <i>all</i> of my major codebases supporting 2.x-3.x. Particularly, Mako templates supports <i>python 2.4 all the way through 3.x with no conversion</i> - and Mako deals heavily with unicode and Python AST structures.<p>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 think that the ideas and tips of the article are useful, but I don't like the opening phrase.<p>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.<p>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.<p>(For example, they changed allowed syntax of "if".)
The commit is more interesting than the article:
<a href="https://github.com/sympy/sympy/pull/2318" rel="nofollow">https://github.com/sympy/sympy/pull/2318</a><p>It does fail to mention that you need to also use special exception handling in all cases, eg.<p><pre><code> try:
...
except TypeError:
e = exception()
...
</code></pre>
...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.
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.<p>Seriously, Python3 made me hate python.
A couple examples why:<p><pre><code> - 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
</code></pre>
Let's make a new python4 == python2.7 and forget about all this python3 bullshit.
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.
I'm unclear how this is better than doing, as is mentioned in the first paragraph, a single code base that runs in both 2.7 and 3.x versions?<p>Or is this a case where 2.6 needs to be supported?