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

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

 



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

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux