[Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?
"Martin v. Löwis"
martin at v.loewis.de
Tue Nov 3 20:22:41 CET 2009
>>> I wouldn't say that. For instance, I'm just starting a refactoring that will
>>> result in getmail v.5, but I need to target Python 2.5 and up, so there's
>>> essentially no way the code will run in Python 3.x (as another list member
>> That's a common myth. It is very well possible, using 2to3. You don't
>> have to wait until you can drop 2.5 to start supporting 3.x, out of a
>> single code base.
> I haven't tried this, but I was relying on Daniel Stutzbach's opinion posted
> here earlier:
> It's pretty easy to make Python source that works under 2.6 and 3.x. It's
> basically impossible to make Python source that works under 2.4/2.5 and
But that's a completely different statement. "make code that works on
both 2.x and 3.x" is *entirely* different from "make code written for
2.x also run on 3.x". The latter is less constrained: to run it on 3.x,
you can convert it to 3.x first, using 2to3. So it would not be the
*same* code that runs, but you can have single source code for both
2.x and 3.x - only that what you run is not literally the source code.
> getmail v.5 will be released in a month or three. And many of its users will
> still have Python 2.5, so that's what getmail has to run on. Perhaps Daniel's
> comment is incorrect (I have no evidence either way), but if it is true that
> having a single getmail codebase run on Python 2.5 and Python 3.x is
> "basically impossible", then I won't be too concerned about 3.x for a while
No no no. Daniels comment is correct, in that you can't run the code
*unmodified*. However, it is well possible to have a single code base
for both 2.x and 3.x - you just don't *run* the code on 3.x (but convert
it first, e.g. at installation time).
> I've been an avid Python user and promoter since 1.2, but saying "drop Python
> 2.x and switch to 3 now" is simply not realistic in any of the environments in
> which I use Python daily.
And I wouldn't say that. Instead, I say "support both 2.x and 3.x from a
single code base". That approach can work for supporting everything from
2.3 to 3.2 (perhaps even from 2.0 to 3.x).
More information about the Python-Dev