[csw-maintainers] Python 2.7

[Maciej (Matchek) Bliziński]

2013/7/29 Peter FELECAN <pfelecan at opencsw.org>:
>> Can we prevent the above scenario in any way? For example, provide a
>> stub for 2.6 that when you try to import it, it would say: "this
>> package is for Python 2.7 only"?
>
> Meh. I don't know. It seems contrived to me.

Contrived ‒ the problem or the solution? The problem seems pretty
straightforward to me: you install CSWpy-foo and "import foo" fails.

>>> 2. The package provides a "mixed" module, i.e. the code runs on 2.6 and
>>>    2.7 interpreter. In this case it should provide a double pronged
>>>    installation, i.e., components installed in
>>>    /opt/csw/python/site-packages.
>>
>> Or instead, let's just provide files in
>> /opt/csw/python2.6/site-packages and /opt/csw/python2.7/site-packages
>> plus their compiled .pyc counterparts, compiled with respective
>> interpreters. Simple to do and effective. Why shouldn't we do this?
>
> Indeed. What I thought but not wrote...

Cool, we have agreement on this one. It should be fairly easy to
implement with GAR modulations. I already briefly talked about this
with Dago.

>>> consequently, no need for a specific
>>>    prefix and its dependency specifies CSWpython *and* CSWpython27.
>>
>> Agreed on the deps. (Also note: if we had CSWpy26- and CSWpy27-, we
>> could be more selective.)
>>
>>> 3. The package provides a 2.6 module (IMHO this is also a 2.7
>>>    module).
>>
>> It surely is, except the 2.6 .pyc files won't work for 2.7.
>
> Are you sure of that?

Yes, see here:

$ mkdir pyc_test
$ cd pyc_test
$ echo "print 'foo'" > foo.py
$ python2.6 -m foo
foo
$ python2.6 -m py_compile foo.py
$ ls -l foo.pyc
-rw-rw-r-- 1 maciej maciej 106 Jul 29 15:44 foo.pyc
$ mv foo.py foo_renamed.py
$ python2.6 -m foo
foo
$ python2.7 -m foo
/usr/bin/python2.7: No code object available for foo

> Anyway, the .pyc is rejected and .py is used which
> incurs just the extra parsing, isn't it?

Yes. Here's the hierarchy of usefulness:

- providing the right .pyc file
- is better than not providing a .pyc file at all
- which in turn is better than providing the wrong .pyc file

We can accept this as a temporary state, but we should work towards
the dual 2.6+2.7 support.

> What I propose is eventually to support 2.x and 3.x.

I don't know if we can talk in terms of 2.x or 3.x. We aim to support
2.6, 2.7 and 3.3. We currently do not support 2.5 (even though 2.5 is
a 2.x) nor 3.0 or 3.1 or 3.2. We'll drop the 2.6 at some point when
everything works well with 2.7.

By the way, do you haven an idea how to deprecate the old 2.6 modules?

> Can I commit the changes?

Go ahead. I'll add the check to make sure we're not introducing
regressions for 2.6.

Maciej