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

[Toshio Kuratomi]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080529/f792d997/attachment.bin