Those two controversial 2nd & 3rd paragraphs of my ch 1
gagsl-py2 at yahoo.com.ar
Thu Jan 14 05:06:55 CET 2010
En Wed, 13 Jan 2010 17:11:18 -0300, Daniel Fetchinson
<fetchinson at googlemail.com> escribió:
>>> Again, django has been ported to python 3, that's fine, everybody
>>> acknowledges that, but it's not the case that one code base works with
>>> both python versions.
>> Well, if the port is done via 2to3, you can install the same code base
>> Python 2 and Python 3, and the distutils install mechanism will run an
>> automated transformation over the code during the installation. If
>> there is
>> no manual interaction required to run the code on both platforms, I
>> say that qualifies as "one code base works with both Python versions".
>> not different from generating code or specialised config files during
>> installation or similar things.
> This is all true, but what we were talking about is not exactly this,
> but rather having a single code base running unmodified on python 2
> and 3. Another poster actually supplied an example: crunchy.
Having separate code bases for 2.x and 3.x would be a nightmare. I'm still
suffering because of some decision taken years ago here at work: someone
decided to make separate projects per customer, that were essentially the
very same product (with small modifications and additions for each
customer). Not even branches in the version control system: completely
separate projects. That's insane.
So I try hard not to have separate branches for 2.x and 3.x code, and
until now the strategy outlined by Steve Holden has worked fine for us.
Basically, we only consider "source" the 2.x code; the 3.x code is
"derived", not source (like compiled .pyc files or .exe executables) as
isn't even under version control (to avoid the temptation to patch the
generated 3.x code).
The Python 3.1 interpreter doesn't run the very same code as the 2.x one,
but for all practical purposes, we have a single code base for both 2.x
>> > I think django and cheetah
>> > doesn't count because they simply take their python 2 code, run it
>> > through 2to3 which gives them a python 3 code (I could be wrong
>> > though). Two codes for the two python versions.
>> But just one code base that has to be maintained. And I think the
>> maintenance is the main aspect here.
> This is true again. But where it all started is Alf's sentence in his
> book. And I think he has a point there, it might be possible to do
> this (single code base for both versions), but it's not easy.
Some syntax constructs simply aren't compatible, like try/except. And
u"ABC" is invalid in 3.x, but "from __future__ import unicode_literals"
cannot always been used. Generating the 3.x source with 2to3 -in my
experience- is easier than restricting oneself to write code using only
the subset of compatible features, which leads to non-idiomatic code style.
It *can* be done, as some examples show -- but I prefer the 2to3 approach.
More information about the Python-list