[Python-Dev] What to do for bytes in 2.6?

glyph at divmod.com glyph at divmod.com
Fri Jan 18 07:11:17 CET 2008


On 04:43 am, guido at python.org wrote:
>Just being able to (voluntarily! on a
>per-module basis!) use a different type name and literal style for
>data could help forward-looking programmers get started on making the
>distinction clear, thus getting ready for 3.0 without making the jump
>just yet (or maintaining a 2.6 and a 3.0 version of the same package
>easily, using 2to3 to automatically generate the 3.0 version from the
>2.6 code base).

Yes!  Yes!  Yes!  A thousand times yes!  :-D

This is *the* crucial feature which will make porting large libraries 
like Twisted to 3.0 even possible.  Thank you, Guido.

To the critics of this idea: libraries which process text, if they are 
meant to be correct, will need to deal explicitly with the issue of what 
data-types they believe to be text, what methods they will call on them, 
and how they deal with them.  You cannot get away from this.  It is not 
an issue reserved for the "pure" future of 3.0; if your code doesn't 
handle these types correctly now, it has bugs in it *now*.  (In fact I 
am fixing some code with just such a bug in it right now :).)

It is definitely possible to make your library code do the right thing 
for different data types, continue to support str literals in 2.6, and 
eventually require text / unicode input (after an appropriate 
deprecation period, of course).  And it will be a lot easier if the 
translations imposed by 2to3 are as minimal as possible.
>Note that I believe that the -3 flag should not change semantics -- it
>should only add warnings. Semantic changes must either be backwards
>compatible or be requested explicitly with a __forward__ import (which
>2to3 can remove).

This also sounds great.


More information about the Python-Dev mailing list