[Python-Dev] The bytes type

James Y Knight foom at fuhm.net
Tue Jan 16 10:37:11 CET 2007


On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:
>> The benefit (to me, and to many others) of 3.x over 2.x is the  
>> promise
>> of getting rid of cruft.
>> If we're going to re-add cruft for the sake of temporary
>> compatibility, we may as well just stick with 2.x.  You have to  
>> take a
>> quantum leap sometimes or you end up working around the same old
>> mistakes.
>>
> There seems to be rather a lot of confusion. No one is suggesting  
> Python 3.0 be anything less for the sake of backward compatibility.  
> Instead, it has been suggested Python 2.6 (and possibly 2.7) be  
> something *more* in order to provide for an easier upgrade path. No  
> compromises in Python 3.0.
>

True: nobody is suggesting python 3.0 be anything less. But, I am  
indeed suggesting that Python 3.0 be something *more*: I am  
suggesting that people keep in mind the ease of writing of a program  
which can run on both 2.5 and 3.0. And wherever possible, act so as  
to preserve that ease. That may indeed involve a "compromise" in 3.0.

Given that Python 3.0 is supposed to be released in ~ 1.5 years (I  
guess), around the same time as the 2.6 release, I do think 3.0 ought  
to have a compatibility story that doesn't depend on 2.6. My goal  
here is not to get Py3.0 to be backwards compatible, it's to get the  
intersection of 2.5 and 3.0 to be large enough that I can explicitly  
write code to that intersection without having to tear my hair out  
and make the code incredibly gross (or worse yet, not be able to do  
it at all). See previous iteritems() example.

I really don't see why there's such an urgency for removing things  
IMMEDIATELY in Python 3 that don't have a suitable replacement in an  
already released version. There's plenty to remove which already does  
have a suitable replacement. I think the major cruft all falls into  
this category (unicode strings already exist, newstyle classes  
already exist, non-string exceptions already exist. The 'bytes' type  
doesn't exist yet, but I expect can be introduced in such a way that  
it has a useful intersection of functionality with the current method  
of using 'str' to hold bytes.)

I'd like to remind everyone that 3.0 won't be the last version of  
python ever released (at least, I hope!). Where Py 3.0 introduces a  
brand-new way to do something, the old can be removed at a future  
date. Mark it as deprecated, so that nobody will use it in new code,  
and remove it a few more versions down the line. Getting rid of cruft  
is great...but you can't properly call something "cruft" when it's  
the only way.

Allowances for writing portable code could make a big difference in  
speed of adoption. I expect Python 3.0 will be a "quantum leap", even  
if people don't have to rewrite everything from scratch or fork their  
codebases to keep compatibility with both releases. There's plenty to  
look forward to, and I'd love to actually be able to actually use it.  
But I need to be able to run 3rd party libraries, and the 3rd party  
libraries must still remain compatible with earlier releases. If  
those requirements are incompatible with using Py 3.0, it'll be a shame.

James


More information about the Python-Dev mailing list