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.
_______________________________________________
QP mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/qp
