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

Toshio Kuratomi a.badger at gmail.com
Mon Jun 9 16:56:55 UTC 2008


Matej Cepl wrote:
> On Mon, 02 Jun 2008 21:15:33 -0400, Ignacio Vazquez-Abrams scripst:
>> On Mon, 2008-06-02 at 22:58 +0200, Christoph Höger wrote:
>>> 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?
>> Python 2.x *will* be discontinued at some time in the future. It may be
>> a few years, but it will happen.
> 
> Wouldn't it be more prudent to upgrade just to python 2.6 (asap) and let 
> one or two Rawhide cycles to make all warnings disappear?
> 
I had a look at python-2.6 vs (python-2.5 and python-3.0) this weekend. 
  It looks like this might be a viable path.  Here's what I found::

* 2.6 appears to be mostly compatible with 2.5.x.  Porting from 2.5.x to 
2.6.x seems like it will be pretty routine stuff.

* 2.6 seems to be mostly compatible with 3.0 if you use from __future__ 
import all-the-stuff-that-changed.

* It appears that we can mix these with file-level granularity.  If this 
works out we should be able to port individual modules to 3.0 syntax 
while other modules stay on 2.x.

Outstanding issues I saw:

* There are some corner cases around unicode handling.  2.6.x with from 
__future__ does translation so string literals ("Hello World") become 
type ``unicode`` instead of type ``str``.  In 3.0, the implementation of 
``str`` is what ``unicode`` is, ``unicode`` no longer exists, and 
``byte`` is what ``str`` was.  Most things that returned ``str`` will 
now return ``unicode``.  This will have issues for:

   * Code that checks for unicode type will run on 2.6 but break on 3.x. 
  This includes things like to_unicode()/to_utf8() functions that 
translate between encodings of unicode and the ``unicode`` type.
   * Code that loads data from a file, the network, or other source 
external to python *might* break since there's a variety of different 
ways this code can decide to return the data and the behaviour will 
likely change::

   2.x     3.x    Evaluation
   str     byte   Should happen if no decoding of the bytes is done in 
the library.  Means that things like "print (output)" will no longer 
work right as this is now a sequence of bytes rather than a string.

   unicode str    Should happen if the library converts bytes to unicode 
type already.

   str     str    Should only happen if the library is updated to 
convert from raw bytes to unicode.  If it doesn't, it's a bug in the 
library.

   unicode byte   Should only happen if the library drops support for 
converting from bytes to unicode.

Note that there's been updates to file io that may help this:  The 
default encoding is now utf-8 instead of ascii and files that are read 
using: my_file = open(filename, 'r') will yield unicode lines translated 
from utf-8 while my_file =open(filename, 'rb') will yield arrays of type 
``byte``.

* There are incompatible changes to the standard library for 3.x.  These 
changes will affect programs which make use of those modules.  (This can 
happen between 2.x releases as well, just to a different extent).

* Similar to the above point, there have been some changes to 
__builtins__ for 3.x.  This means that file() works in 2.6.x but not in 
3.x, for instance.

So here's a new proposal to shoot down (modified from Jeremy's ideas):

1) Fedora 10 ships with the latest python-2.5.x.
2) The Fedora 11 development tree switches to python-2.6.x soon after 
F10 is released.
3) We start packaging 3.x versions of modules in preference to 2.x 
versions where it makes sense (ie: upstream is shipping 3.x based 
releases; the 3.x code doesn't depend on any of the 3.x library 
reorganization.)
4) We port our own code to run on 2.6.x with from __future__ import 
-everything-that-3.x-changes.
5) At the start of F12 development and every release thereafter we 
evaluate how many modules we still ship that are 2.x only, how much 
longer py-2.6.x is going to be supported, and how much further 
python-3.x has diverged from python-2.6.x.  At some point the 
cost-benefit will be such that we move to python-3.x, port upstreams to 
py-3.x or abandon them, and make sure our code runs on "the real" 
python-3.x.

Risks:
* We don't know how compatible python-2.6 and python-3.x will be until 
they are released.  We don't know how compatible they will remain 
through the life of python-2.6 and as future releases in the python-3.x 
series are made.

* We may have to port some code twice, once for "2.6-in-3.x-mode" and 
once for the real 3.x (but the ports should each be smaller sizes)

* Code we port will need to run on python 2.6 or higher.  There will be 
no way to run code on both python <= 2.5.x and python >= 3.x.  In 
particular, this means that RHEL/CENTOS-5.(0,1,2) will not run the code 
we port.  Infrastructure Group members, take note of this :-(.

* We'll be using python-2.6 as a bridge between py-3.x and py-2.x code 
(Code ported to 3.x importing code written for 2.x and vice versa).  We 
don't know how well tested and maintained that use-case will be. (But we 
can hope it's well maintained as it does make transitioning between 
python-2.x and python-3.x easier, which is one of 2.6.x's goals.)

-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://listman.redhat.com/archives/fedora-devel-list/attachments/20080609/b3e6a286/attachment.sig>


More information about the fedora-devel-list mailing list