Those two controversial 2nd & 3rd paragraphs of my ch 1

Daniel Fetchinson fetchinson at googlemail.com
Wed Jan 13 15:11:18 EST 2010


>> 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 in
> 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 would
> say that qualifies as "one code base works with both Python versions". It's
> not different from generating code or specialised config files during the
> 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.


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

>> Just to be clear I'm looking for an example where one given
>> code runs on python 2 and 3 unmodified.
>
> lxml for example. Not only the Cython compiled part (which is automatically
> portable anyway), also all of its Python code base and its entire test
> suite. It runs on all Python versions from 2.3 through 3.1, and it doesn't
> use 2to3 or any other kind of code modification.
>
> The regular Python code base was almost trivial to port, but porting the
> test suite was actually quite involved. The main reasons for that were a)
> doctests and b) the requirement to test exactly string input/output and
> exactly unicode input/output on both platforms. Most code simply doesn't
> have that requirement, but lxml does.

Cool, that's another example I was unaware of, thanks!

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown



More information about the Python-list mailing list