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

[Toshio Kuratomi]

> 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.

Another one:

dict.keys() no longer returns a key.  This will break code like::

   my_dict = {'one': 1, 'two': 2, 'three': 3}
   for key in my_dict:
       if key == 'three':
           del(my_dict[key])

In python-2.6 this will work because we'll be iterating over a temporary 
list of keys.  In python-3.0, we'll be iterating over something that's 
tied into the state of the dictionary.. so del() will change the state 
and python will raise an exception.

-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/20080616/d6ae3de4/attachment.sig>