Greetings to all!

A few nights ago, I decided to attempt the py2to3 recipe that David
describes below, on evoque. Apart from an earlier snag to get py3
installed properly on os x (bug in py3), once started with porting the
code base to run on both py2 and py3... it was pretty plain sailing, I
ended up finishing it in one sitting. Finishing it to the point where
the unit tests run on all of py2.4 thru to py3.0, minus the tests that
depend on 3rd party modules not yet available for py3 (e.g. markdown).

The code changes are almost minimal, and less than I would have
expected. And, in the end the runtime package gained literally less
than a handful of lines of code (on a total that is a little under 1K
lines of code). The updated release should be forthcoming shortly...

For me it boiled down to mostly just putting this one block in one of
the modules:

+if sys.version < '3':
+    unistr, string = unicode, basestring
+    from cStringIO import StringIO
+else:
+    unistr, string = str, str
+    from io import StringIO

and then, to avoid repetition, import what is needed by other from it,
e.g.

+from evoque.evaluator import StringIO

One thing, not mentioned explicitly in David's recipe, is not being
able to find a common way to express relative imports... as the syntax
in py3 for that is:

from . import submod
from .. import mod
from ..mod import submod

I ended up using absolute imports everywhere, e.g.:

-from template import Template
+from evoque.template import Template

This is a little annoying, as it forces a possibly inappropriate
change, but it seems to not cause any problems anywhere.

There may still be some lurking issues when running evoque on py3 that
may show up when migrating more specific applications, but I would be
surprised if they'd prove to be non-trivial to resolve.

mario


On Dec 5, 2008, at 9:03 PM, Binger David wrote:

> 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.