[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]