The migration path that most attracts me is to one-by-one migrate low-level modules to Python 3 (with Python2to3 plus hand editing until unit-tests pass), and declaring the Python 3.x version to be the master, delete the original and regenerate it with Python 3to2, and checking the unit-tests pass.

Slowly the Python 3 version will be constructed while maintaining a Python 2 version working at all times. Eventually, there will be one code-base, directly running Py 3 and acting as source for an auto-generated Py2 version. At that point, production can migrate to Python 3, and the auto-generated version can be allowed to wither.

My question being: If I use Python 3.4 enum types, with Python 3to2 be able to convert it meaningfully into Python 2.7 code?

This is definitely in the “that would be nice” category.

Basically, there emerged a philosophical difference over whether enum values should be of a different type than the enum itself; e.g. should Color.red and Color.blue be of type Color, or should they be of some separate EnumMember type? The former view (adopted by PEP 435) has implications that severely restrict subclassing; the latter view (taken by flufl.enum) was ultimately found unattractive by Python’s creator.

Regardless of when or if the above PEP is accepted, you can get substantially the same functionality from Barry Warsaw’s flufl.enum, which works on both Python 2.7 and Python 3.2+, according to the package documentation. (The PyPI entry lists 2.6 as well, but I am not sure if this information is up to date. Presumably older versions of the package did work with 2.6, and they’re still available.)

And now to go edit Wikipedia… for unrelated reasons.

Two things jump out at me:

1) After 3 years of using PEP 8, the space after the comma and the spacing around the % operator seem completely natural and obvious. Only some sort of uncouth barbarian would leave them out!

2) The title contains the word “FALSE”. Python is case-sensitive. It should read “False”.

Alastair, I may steal your line…