With the final release of Python 3.0 arriving soon, more developers are discussing transition strategies to move from "2 to 3". Perhaps some should consider a strategy to support "2 and 3".
Fabio Zadrozny noted yesterday a number of tips or workarounds for simultaneously supporting applications in both Python 2.x and 3.x - a great notion - maybe a 2 and 3 (as opposed to a 2 to 3) best practices FAQ should be started somewhere. I've got a few to add to the collection which I'll post in due course.
I'm not sure that all applications will be able to neatly support both major versions of Python with the same code base, although it does seem to be to be an objective worth due consideration.
Should application code bases co-exist on both? Perhaps the pivot point is a judgement call on how many compatibility shims one has to shove into the code base to support both.
In Python 3000 Status Update Guido van Rossum outlines a transitional development approach, suggests porting projects to 2.6 first, using the command line flags to show 3.x warnings and deprecations, as an aid to getting to 3.0. Subsequently in Python 3000 and You (See also Guido's presentation [PDF]) he urged developers to be considerate of the users of their APIs when moving up to 3.0. This appears to be the approach the Twisted folks have chosen to follow.
Still, despite some consternation over py2/py3 migration or dual-support strategies having been expressed in the pythonosphere, successful examples of packages with dual 2/3 support may prove to be more common than was anticipated.
As an example we can look at QP and its supporting friends QPY, Durus, Dulcinea, and Sancho, all of which will support from the same code base both Python 3 and 2.x when version 2.1 of the QP web application framework is released upon Python 3.0's release. You won't find a lot of complicated hacks or compatibility shims lurking in every module.
Given that the QP-suite encompasses a full stack web application development environment including a Python object database engine, it would seem to be self-evident that it is possible to write non-trivial applications that simultaneously, and cleanly, support the old and new eras of Python. Kudos to the Mems-Exchange folks!
Kudos also to the Python language developers. On balance I really like Python 3 and look forward to seeing increasing numbers of packages available on it. If I was forced to single out one change which I like the best, it would be that the Unicode type / u'' has been done away with. All strings are now "unicode" and utf-8 as a default encoding makes so much sense in this day and age. Unlike in the 2.x world, Python 3 users will generally avoid problems with mixing encoded and unencoded text. Of course this comes with a price - any code which used Unicode and encodings will need updating - but its a price well worth paying for the long run.
For those who remain confused over Unicode in 2.x, I recommend you install a sandbox Python 3 environment and play. Visit the What is Unicode? page and grab some funky UTF-8 encoded strings and start playing in 3.0 and notice how much less thinking you need to do...
There are other cross-compatibility hurdles many non-trivial applications and scripts will need to leap and I'll try to document those few I've jumped personally. In the next instalment lets dive right in and deal with using metaclasses in both Python 2 and 3. It is easier than you might suspect.