[Python-Dev] [RELEASED] Python 2.7 alpha 2

"Martin v. Löwis" martin at v.loewis.de
Wed Jan 13 20:33:24 CET 2010

> Note that increased 3.x compatibility in the most recent 2.x release
> will always help in two scenarios:
> 1. New projects that want to use 2.x only libraries but want to be ready
> for the Py3k transition in their own code (e.g. new 2.7 features like
> set literals, dict and set comprehensions and the view* dict methods can
> be translated far more cleanly by 2to3 than the closest comparable 2.6
> code).

Of these, I can only see this being the case of the view* methods.

Why would set literals allow for code that more cleanly translates
to 3.x? Suppose you write

 f = set((1,2,3))

in 2.6. That code will work *exactly* the same way in 3.1, no
translation needed at all. Likewise for dict and set comprehensions:
the code is as cleanly translated in the 2.7 form as it is in any
prior form (ie. no modifications).

As for view* methods: there is one important exception where
the 2.6 equivalent is as cleanly translated as a view method:

for key in D:

This is a more modern equivalent for iterating over D.keys(),
so if your code still does the latter, just change it to the
former (requires Python 2.2). I'd claim that this is the dominant
case of traversing a dictionary (probably followed by iterating
over .items()). So while it is true that only view* can be
transformed correctly, I'd claim that this is an infrequent

> 2. Similarly new projects that use a 3.x trunk can be more readily
> translated to a 2.7 version with 3to2, whereas some constructs may be
> difficult to recreate in earlier Python versions.

That may be true, but is besides the point here: the issue was whether
a 2.8 release might help in migrating to 3.x. People who follow this
approach already have 3.x code. Whether they would rather port to 2.8
only, and get that work with little effort, or whether they would port
to 2.5 and later, and put in more work, I don't know - I guess we would
have to ask these people. I would expect that they prefer if 2.x
died rather sooner than later, because they can then stop supporting


More information about the Python-Dev mailing list