[Python-Dev] What to do for bytes in 2.6? (original) (raw)

Guido van Rossum guido at python.org
Sun Jan 20 22:04:44 CET 2008

On Jan 20, 2008 6:56 AM, Aahz <aahz at pythoncraft.com> wrote:

On Sat, Jan 19, 2008, Guido van Rossum wrote: > > I believe that a constraint should be that by default (without -3 or a > future import) str and bytes should be the same thing. Or, another > way of looking at this, reads from binary files and reads from sockets > (and other similar things, like ctypes and mmap and the struct module, > for example) should return str instances, not instances of a str > subclass by default -- IMO returning a subclass is bound to break too > much code.

This makes perfect sense to me. And yet, I also like the idea that b""+u"" raises an exception. I have a suggestion, then: for 2.6, let's make bytes a subclass of string whose only difference is that it contains a flag.

This still begs the question which standard APIs should return bytes.

I don't care whether b""+u"" raises an exception. This should be enough for people on an accelerated 3.0 conversion schedule, and they can write their own test for the flag if they care.

Well, it being a subclass, it doesn't even need to have a flag, right? The class itself acts as a flag.

But still, without support from built-in and standard library APIs I fear it's not going to be very useful.

And fixing all the standard APIs to make the correct distinction is going to create exactly the ripple effect that Raymond so desperately wants to avoid -- and I agree, to the extent that rippling this through the stdlib is a waste of time from the stdlib's POV -- it's already been 3.0-ified.

For 2.7, we can start tightening up. b""+u"" can raise an exception, and the socket module might use a RETURNBYTES variable.

To put it another way, I don't think we should consider 2.6 the stopping point for 2.x/3.x conversion help. There's nothing wrong with planning for features to go into 2.7 -- just as several PEPs in the past have had multi-version planning.

Personally, I very much doubt there will be a 2.7. I certainly don't expect to participate in its development the same way I am trying to steer 2.6.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list