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? > This is even _more_ true with things which are a framework that lots of > other packages provide modules for -- things like apache, perl, python, > and more. So in contrast, I think that we should evaluate python 2.6 > for Fedora 10 (it seems reasonable, but I will defer to the current > python maintainer's judgement :-). I completely agree. In theory the change will be smaller and less incompatible if you first port to the subset of python-2.6.z that is most compatible with python-3.y.z, however I've not seen anyway to test that you've successfully done this apart from inspecting the code by hand. > And the move to python 3.0 will need > to wait until there's either > a) sufficient reason for us to do a lot of legwork to get there or > b) enough upstreams are "buying in" > > > * python3000 modules should have a separate namespace from python2.x > > modules. The packaging committee will need to decide on that > > (python3-foo, python3000-foo, python3k-foo are possibilities. > > python3.0-foo should not be considered as 3.x versions should not have > > the same backwards incompatibilities that 2.x->3.x has.) > > Except that many python modules are just included in with packages or in > the same source tree. This then ends up with a need to build multiple > versions of python modules and that way lies massive amounts of pain. > It was a huge enough pain for just a very small number of modules in the > python 1.5 -> python 2 transition. With the vastly greater number of > modules these days, it becomes far far more difficult. Right, all of the bindings will be a big pain point (does swig support py3k yet?). Also having every package that uses python be renamed from foo to py3k-foo is horrible ugliness we'll have to live with forever. > > * 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). -- James Antill <james.antill@xxxxxxxxxx> Red Hat
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
