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