[csw-maintainers] Python 2.7
Peter FELECAN
pfelecan at opencsw.org
Fri Aug 2 09:59:22 CEST 2013
"Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:
> 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.
The new 2.x is stricter. Well, in this case I concede that you have an
example, a weak one but however it falsifies my conjecture :-)
>> 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.
I'm not convinced but I concede...
>>>> 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.
So, in this case, you agree that for 2.x modules the prefix is just
CSWpy- and for 3.x modules is CSWpy3- ?
--
Peter
More information about the maintainers
mailing list