RELEASED Python 2.6a1 and 3.0a3

Carl Banks pavlovevidence at
Sun Mar 2 11:53:08 CET 2008

On Mar 2, 4:02 am, Kay Schluehr <kay.schlu... at> wrote:
> On 2 Mrz., 06:53, Ben Finney <bignose+hates-s... at>
> wrote:
> > One of the stated goals of the migration is that the '2to3' program
> > will only migrate Python 2.6 code -> Python 3.0 code.
> Yes, I know. Why?
> "The master said so" isn't an entirely satisfying answer. What are the
> *technical reasons* that make it hard to apply '2to3' directly on
> Python 2.4 or Python 2.5?

Well, even if you wanted to apply 2to3 to Python 2.5, you'd (probably)
have to modify your code to make it 2to3-compatible.  So if you're
going to do that, you might as well upgrade to 2.6 to take advantage
of new warnings and new idioms that are more conducive automatic

2to3 is not a general tool to convert any given source code from 2.6
to 3.0.  It's designed to make it possible to write code that works in
Python 2.6 and Python 3.0, but to do that you have to use a
"transitional Python" dialect that's a subset of 2.6.  (It would be
quite  to attempt a general code translator, of course.)

Anyway, I think there are a few cases in Python 2.5 where there's no
easy way to write something that 2to3 can handle, and some
specifically transitional features were added to 2.6 to remedy this.
I don't recall specifics, though.  It may be for the cases where
things that previously returned lists now return iterators.

Finally, 2.6 will have the benefit of being cross-checked with 3.0 to
ensure that 2to3 does what it's supposed to when used as intended.
All bets are off if you attempt it with 2.5.

In the end, the real *technical* reason might have been the developers
thought it wasn't worth the effort to backport it to 2.5.  The above
problems were probably solvable with enough effort, but would that
have been a wise use of resources?

One parenthetical I will add: 2to3 always seemed to me to be more of a
way to enfore constraint on the design of Python 3.0.  If a proposed
feature couldn't be automatically ported to 3.0, then it was a big
strike against the proposal.  That it could end up being a useful
transitional tool is nice, but it never seemed to be its primary

Carl Banks

More information about the Python-list mailing list