Re: Switching to Python 3

2012-08-14 Thread Konstantin Zemlyak 

FWIW an old idea I had for revamping how we maintain Python packages
can
be seen here:
http://lists.fedoraproject.org/pipermail/python-devel/2010-March/000213.html
with some further ideas here:
https://fedoraproject.org/wiki/DaveMalcolm/PythonIdeas
(you can tell that page is old, it still mentions Unladen Swallow and
Pynie...)

I still like the basic idea: introduce a tool that captures the info
on
python runtimes for a given release in one place, and use it
programmatically within specfiles to avoid copy&paste.  Although the
proposal isn't complete (how to handle exclusions?), I'm still fond
of
it.



Personally, I like the idea. As you say, there are still some issues, but I 
guess we could solve those easily.
There is IMHO one downside of this approach - the complexity. I fear that 
rpm-pyconfig can be easily taken to such extremes, that we will end up with 
completely unintelligible specfiles.
As for supporting more runtimes (e.g. Pypy), I would be very careful about 
that, as it might get us overloaded by tons of issues of different packages 
with different runtimes.
Here is a wild idea: Would it be possible to create a common site-packages 
directory for all runtimes? I don't know much about how different runtimes 
handle bytecode generated by another runtime etc, but it may be worth looking 
into, if we want to support more runtimes with our packages.


While this is pretty nice idea it's not feasible unless all runtimes 
support http://www.python.org/dev/peps/pep-3147/ and 
http://www.python.org/dev/peps/pep-3149/ which will require some 
backporting in 2.x series.


--
Zart
___
python-devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Switching to Python 3

2012-08-14 Thread Nick Coghlan 
On 08/14/2012 05:12 PM, Konstantin Zemlyak wrote:
> [Bohuslav Kabrda]
>> Here is a wild idea: Would it be possible to create a common
>> site-packages directory for all runtimes? I don't know much about how
>> different runtimes handle bytecode generated by another runtime etc,
>> but it may be worth looking into, if we want to support more runtimes
>> with our packages.
> 
> While this is pretty nice idea it's not feasible unless all runtimes
> support http://www.python.org/dev/peps/pep-3147/ and
> http://www.python.org/dev/peps/pep-3149/ which will require some
> backporting in 2.x series.

As Konstantin noted, this isn't really feasible except in Python 3.2+.
Enabling that kind of thing is *why* those PEPs exist (although the
binary one is also there due to the way Debian/Ubuntu handle multiarch
support), but that doesn't help when we also want to deal with 2.7.

Backporting is a very dubious idea, as it changes the APIs visible at
the Python level (you need at least the "source_to_cache" and
"cache_to_source" APIs), and application code won't expect those to be
present when the version is less than 3.2. Even worse, the behavioural
change is known to break some programs that assume the source to cache
mapping is just "source_fname + ('c' if __debug__ else 'o')". While that
assumption is technically relying on an implementation detail, breaking
it in an distro patch would not be a popular decision (to say the least).

However, I think it's enough to place a clear upper limit on the number
of runtimes to be supported (where 'x' is the relevant minor version
packaged in the Fedora repos): CPython 2.x, PyPy 1.x, Python 3.x (with
shared site-packages)

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
___
python-devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/python-devel