durusmail: qp: Porting Durus/QP/Qpy to py3k
Porting Durus/QP/Qpy to py3k
2008-12-05
2009-01-10
Porting Durus/QP/Qpy to py3k
Binger David
2008-12-05
The new releases of our packages work with Python 2 *and* with Python
3.0.
The Py3k team has a recommended migration strategy involving the use
of their
2to3 conversion package and then maintaining separate releases for the
two different flavors of Python.  The prospect of maintaining different
branches was unattractive, so we decided instead to try adjusting
our code so that it would work with both Pythons.  As others face
this problem, perhaps it is worth describing our experience.

First we just tried running our code with py3k and noticed right away
that our old code did not fit py3k's syntax.  We adjusted the code as
required
to use rely exclusively on the syntax that is common to Python 2 and
Python 3.
That meant that we could not use all of the sweetest constructs, but
we were willing to pay that price.  It didn't take too long to get all
of the
code converted so that it would at least compile with Py3k.

Once that was done, we went on to hammer our way through unit tests and
make changes as necessary to make them work.  In some cases where
modules
in the standard library have changed names, we use 'if sys.version <
"3":'
blocks to get the right imports for each version.  We searched out calls
of zip(), filter(), and map() and wrapped them in list().  We removed
u'blah' syntax and used as_unicode('blah') instead, where as_unicode()
is defined differently for different versions.  We added __bool__ =
__nonzero__
to our classes that define __nonzero__.  We got rid of __cmp__() and
added
rich comparisons where it was needed.  We fixed the arguments in our
calls to the sort() method.  After a period of making
transformations of this type, the unit tests passed and we were able
to do more testing by running QP's demo applications and our own
applications
in py3k, and this exposed some more issues that our unit tests did not
catch, but we dealt with them using the same methods of correction.

Now our entire code base, public and private, runs in Python 2 and
Python 3.
We're in no hurry about it, but when we do decide to migrate our
production
systems to Python 3, we think it will be like jumping a creek, not the
Snake
River Gorge.











reply