Let's make a plan for python3.0 in Fedora 10+
katzj at redhat.com
Mon Jun 2 14:56:11 UTC 2008
James Antill wrote:
> On Sun, 2008-06-01 at 17:36 -0400, Jeremy Katz wrote:
>> Toshio Kuratomi wrote:
>>> The python programming language is going to be releasing a new version
>>> sometime around the time of the Fedora 10 release. Unlike past
>>> releases, this one will have wide-spread backwards incompatibility in
>>> the python language itself. We need to think about how we want to pull
>>> the new language into the distribution and porting of existing
>>> apps/modules. Here's a proposal to start us off but I hope geppetto
>>> (the python maintainer) and ivazquez (who maintains python3.0 packages
>>> in his spare time_) will weigh in with their thoughts.
>> So, while this is a large and incompatible change, there are lots of
>> other large and incompatible changes that we've managed over the years.
>> And in most of those, we've been far better off with actually making
>> a transition rather than trying to keep two different things around.
> While you obviously have more direct experience than I, can you think
> of a case where a change was this large and incompatible?
python 1.5 -> python 2 wasn't this large. But it was pretty large and
ended up requiring a number of source changes in modules.
>>> * Porting to python3000 will occur at some point but that should be a
>>> post-Fedora 10 feature that we decide on after python-3.0 final has been
>>> released. We will also need to discuss whether to port our tools
>>> piecemeal or altogether at that time and to what extent (if any) we will
>>> allow splitting from any upstreams that only support python-2.x.
>> It's not as simple as that. What happens if (just to make up an
>> example), anaconda and rhpl move to python 3 but no other tools do?
>> Especially given that other tools depend on rhpl. Either a) the other
>> tools have to be ported or b) multiple copies of the same code have to
>> be maintained. The latter is filled with losing. The former is
>> plausible, but it is going to be a big effort and we have to
>> consistently commit to it across the board.
> Probably the most interesting python application is yum, as if it
> breaks you can't easily update/install to fix anything, and it currently
> depends on:
> pygpgme - binding
> rpm-python - binding
> yum-metadata-parser - binding
> ...now all of those and yum need to move to the "py3k language" as one
> unit, and as far as I can see there's no way we can do that
> automatically without renaming everything (at which point we don't need
But to keep things more fun, there's a significant body of other stuff
which sits on top of yum now. So all of that will need to be ported at
the same time also. Doom! :)
More information about the devel