[csw-maintainers] Python 2.7

Maciej (Matchek) Bliziński maciej at opencsw.org
Thu Aug 1 23:49:27 CEST 2013

2013/8/1 Peter FELECAN <pfelecan at opencsw.org>:
> Yann Rouillard <yann at pleiades.fr.eu.org> writes:
>> 2013/8/1 Peter FELECAN <pfelecan at opencsw.org>
>>> Yann Rouillard <yann at pleiades.fr.eu.org> writes:
>>> >
>>> What people need to understand is that a 2.6 non binary module can be
>>>  run by a 2.7 interpreter. The reverse is not always true. This is why I
>>> proposed to replace 2.6 by 2.7 in our next transition from unstable to a
>>> named catalog.
>> I thought Maciej provided a counter-example with the range function where
>> python 2.7 didn't run the code whereas python 2.6 worked. I may have missed
>> something in this long thread, wasn't the example valid ?
> The example referred to compiled code if my memory is good for something
> in this hot weather...

No, it was just the source. range() in 2.6 accepts a float while in
2.7 it throws an exception. It was just an example to show that
testing is required before you can change the interpreter version, and
some form of a migration procedure is required.

> BTW, we didn't decided on the delivery of .pyc and .pyo instead of
> compiling them at installation time. And for this I'm sure that I
> showed the proof.

I think we've agreed to ship *.pyc in the package, because we will not
share one .py file across two Python interpreters: we will provide one
file for the 2.6 interpreter and one file for the 2.7 interpreter.

>>> This is not to be confused with the major incompatibilities between 2.x
>>> and 3.x where using a different prefix is required.
>> To keep thing consistent, I would prefer to have a CSWpy27- prefix if we
>> have a CSWpy3- our CSWpy33- prefix.
>> This way the user will not install a CSWpy- package while looking for a
>> module for python 3.
> First of all, the prefix is/should be CSWpy3 as Debian and tutti quanti.
> Having a CSWpy26- and CSWpy27- prefix is redundantly ugly...
> What about having CSWpy2- for the new packages being them 2.7 or
> modulated for 2.6 and 2.7. The new packages will stub the previous
> ones. This can be done by a scripted rebuild (easy to say, more manual
> work intensive to do). Eventually we have a coherent, orthogonal
> universe. Heh?

Just for the sake of adding a "2"? I'd say no, let's keep it at CSWpy-
and save ourselves and our users the churn of package renames.


More information about the maintainers mailing list