Switching to Python 3

[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