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

[Guido van Rossum]

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 RETURN_BYTES 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/)