FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-30-2008, 04:17 AM
Toshio Kuratomi
 
Default Let's make a plan for python3.0 in Fedora 10+

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.


.. _[1]: http://ivazquez.fedorapeople.org/packages/python3000/

== Proposal ==

* We should review and add the python3000 package to Fedora devel ASAP
so people can work out any bugs with the packaging before F10 release.


* python3000 will not be in the default install for F10. It should not
conflict in any way with the python-2.x package we ship. We should not
port our system tools (system-config-*, anaconda, yum, etc) to
python3000 for F10.


* In F10 modules should not be shipped for python3000 unless upstream is
taking patches for python3000/has a python3000 compatible release branch.


* 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.)


* 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.


== Rationale and Notes ==

* python3000 is backwards incompatible with python2.x. Unicode strings,
print becoming a function, exception changes, removal of old-style
classes, and many other changes will prevent nearly all python2.x
programs and modules from functioning in python3000 without source code
changes. In this way, it is practically a new language.


* Porting to python3.0 as a whole distro will take a significant amount
of time. Being able to break that up and work with upstreams to port
smaller portions at a time will aid us in focusing effort where it's needed.


* python2.6.x will be with us for a long time as Guido has said it will
be supported for a much longer time than the 2.n=>2.n+1 series.
However, that doesn't mean that the 3rd party modules we depend on will
be supported on both 2.x and 3.x.


* Working with upstream module authors on these ports will be extremely
important. There are likely to be upstreams that want to support only
python-2.x or both python-2.x and python3000 for a while. There are
tools to help port from 2.x to 3.x but without upstream to be a point of
distribution for the resulting work we'd bear the burden of maintaining
a fork which we definitely don't want to do.


* Timeline: Sep 03 2008: Python 2.6 and 3.0 final [2]_

* Overview of changes http://docs.python.org/dev/3.0/whatsnew/3.0.html

.. _[2]: http://www.python.org/dev/peps/pep-0361/

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-30-2008, 10:10 AM
Ignacio Vazquez-Abrams
 
Default Let's make a plan for python3.0 in Fedora 10+

On Thu, 2008-05-29 at 21:17 -0700, 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.
>
> .. _[1]: http://ivazquez.fedorapeople.org/packages/python3000/
>
> == Proposal ==
>
> * We should review and add the python3000 package to Fedora devel ASAP
> so people can work out any bugs with the packaging before F10 release.

Agreed... but I'm obviously biased

> * python3000 will not be in the default install for F10. It should not
> conflict in any way with the python-2.x package we ship. We should not
> port our system tools (system-config-*, anaconda, yum, etc) to
> python3000 for F10.

Agreed. Instead, we should work on porting them to at least 2.6 (if not
3.0 outright) for F11.

> * In F10 modules should not be shipped for python3000 unless upstream is
> taking patches for python3000/has a python3000 compatible release branch.

Agreed. We don't want the burden of maintenance.

> * 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.)

Agreed. I started using "python3000-" myself, but I'm flexible.

> == Rationale and Notes ==
>
> * python3000 is backwards incompatible with python2.x. Unicode strings,
> print becoming a function, exception changes, removal of old-style
> classes, and many other changes will prevent nearly all python2.x
> programs and modules from functioning in python3000 without source code
> changes. In this way, it is practically a new language.

To be clear, it will be incompatible with Python 2.5 or earlier. Python
2.6[1] is a way station between 2.5 and 3.0, and can be used to help any
porting efforts.

[1] http://docs.python.org/dev/whatsnew/2.6.html

--
Ignacio Vazquez-Abrams <ivazqueznet@gmail.com>

PLEASE don't CC me; I'm already subscribed
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-01-2008, 09:36 PM
Jeremy Katz
 
Default Let's make a plan for python3.0 in Fedora 10+

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.


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


* 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.


Jeremy

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-02-2008, 02:45 PM
James Antill
 
Default Let's make a plan for python3.0 in Fedora 10+

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@redhat.com>
Red Hat
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-02-2008, 02:56 PM
Jeremy Katz
 
Default 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-02-2008, 03:01 PM
seth vidal
 
Default Let's make a plan for python3.0 in Fedora 10+

On Mon, 2008-06-02 at 10:45 -0400, James Antill wrote:

> 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
>


the other question I have is how many of the 'batteries included'
modules in python will not yet be ported to py3k? I mean if something
like bzip2 or fnmatch or logging isn't ported yet we will have issues.

-sv


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-02-2008, 03:44 PM
Jesse Keating
 
Default Let's make a plan for python3.0 in Fedora 10+

On Mon, 2008-06-02 at 10:56 -0400, Jeremy Katz wrote:
> 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.

Same with the recent perl upgrade, which requires spot and others make a
number of source level changes at at the very least rebuild all the perl
packages. This was accomplished using an 'on the side' repo within
Koji, and an agreement ahead of time to not mess (too much) with perl
packages while the building was ongoing so that the whole mess could be
tagged over to rawhide in one shot instead of weeks of breakage.

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-02-2008, 03:51 PM
"Arthur Pemberton"
 
Default Let's make a plan for python3.0 in Fedora 10+

2008/5/29 Toshio Kuratomi <a.badger@gmail.com>:
> 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.

<snip>

Good looking plan, one suggestion:

Try to maintain a TODO list of things/features that need to be ported
from Python2 to python3000. I would like to try to help, and having a
list that I can pick from would be helpful


--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-02-2008, 08:58 PM
Christoph Höger
 
Default Let's make a plan for python3.0 in Fedora 10+

Hi,

could you point out why exactly there is "something to do"?

I mean, python3000 is a new language and no replacement so if someone is
willing to package it (or a package that depends on py3k) she/he should
make sure its a python2.x compatible installation (especially in the
naming of the package). That should be all, right?

regards

christoph
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-03-2008, 01:14 AM
Ignacio Vazquez-Abrams
 
Default Let's make a plan for python3.0 in Fedora 10+

On Mon, 2008-06-02 at 11:01 -0400, seth vidal wrote:
> On Mon, 2008-06-02 at 10:45 -0400, James Antill wrote:
>
> > 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
> >
>
> the other question I have is how many of the 'batteries included'
> modules in python will not yet be ported to py3k? I mean if something
> like bzip2 or fnmatch or logging isn't ported yet we will have issues.

The stdlib is about 98% ready. The big things to watch for are the
removed modules, not many of which yum et al are terribly likely to use
(md5 and sha, off the top of my head).

--
Ignacio Vazquez-Abrams <ivazqueznet@gmail.com>

PLEASE don't CC me; I'm already subscribed
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 12:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org