"Maciej (Matchek) Bliziński" <[email protected]> writes: > 2013/8/1 Peter FELECAN <[email protected]>: >> Yann Rouillard <[email protected]> writes: >> >>> 2013/8/1 Peter FELECAN <[email protected]> >>> >>>> Yann Rouillard <[email protected]> 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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
