Let's make a plan for python3.0 in Fedora 10+

[Jeremy Katz]

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[1]_) 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
> python-iniparse
> rpm-python           - binding
> urlgrabber
> 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
> to).

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! :)

Jeremy