Matej Cepl wrote:
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::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?
* 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 Evaluationstr 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
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
