[csw-maintainers] Python 2.7

[Peter FELECAN]

"Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:

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

The solution.

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

Good to talk with Dago about this. He can bring his salt.

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

Right. But I wa writing about the case when .py exists and .pyc is from
a earlier version. That works, isn't it?

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

Nah. When I write "support 2.x and 3.x" I mean, support the latest
version of 2 and 3. in Our case 2.7 and 3.3.

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

Thanks.
-- 
Peter