[Python-3000] Immutable bytes -- looking for volunteer

[Brett Cannon]

On 9/25/07, Guido van Rossum <guido at python.org> wrote:
> On 9/25/07, Brett Cannon <brett at python.org> wrote:
> > On 9/25/07, Guido van Rossum <guido at python.org> wrote:
> > > OK, Jeffrey's and Adam's patches were helpful; it looks like the
> > > damage done by making bytes immutable is pretty limited: plenty of
> > > modules are affected, but the changes are straightforward and
> > > localized.
> > >
> > > So now I have an idea that goes a little farther. It relates to
> > > Talin's response (second message in this thread if you're using gmail)
> > > and acknowledges that there are some good use cases for mutable bytes
> > > as well (as I've always maintained).
> > >
> > > How about we take the existing PyString implementation (Python 2's
> > > str, currently still present as str8 in py3k), remove the locale and
> > > unicode mixing support, and call it bytes. Then the PyBytes type can
> > > be renamed to buffer. It is well-documented that I don't care much
> > > about the existing buffer() builtin; it can be renamed to memview for
> > > all I care (that would be a more descriptive name anyway).
> > >
> > > This would provide a much better transitional path for 2.x code
> > > manipulating raw bytes using str instances: just change "..." into
> > > b"..." and str into bytes. (Of course, 2.x code that is confused about
> > > bytes vs. characters will fail hard in 3.0 as soon as a bytes and a
> > > str instance meet -- this is already the case in the current 3.0 code
> > > base and will remain unchanged.)
> > >
> > > It would mean more fixes beyond what Jeffrey and Adam did, since
> > > iterating over a bytes instance would return a bytes instance of
> > > length 1 instead of a small int, and the bytes constructor would
> > > change accordingly (no more initializing a bytes object from a list of
> > > ints).
> > >
> >
> > +0.  While 2to3 would be able to help more, the methods that will be
> > ripped out will make the ease in transition from this a lot less.
>
> Compared to what? The methods to be ripped out are already not
> available on bytes objects.
>

Right, but that doesn't mean we could put others back in or something
to help others with their code transitions.

> > Plus you can have immutable bytes in a way by passing the current
> > bytes to tuple.
>
> At what cost? tuple(b"x"*100) is a tuple of length 100.
>

Right, but the question is how often people will need this.  There is
a reason that mutable bytes were chosen in the first place.

> > > The (new) buffer object would also have to change to be more
> > > compatible with the (new) bytes object -- bytes<-->buffer conversions
> > > should be 1-1, and iterating over a buffer instance would also have to
> > > return a length-1 buffer (or bytes???) instance.
> >
> > Return a byte.  If you want a mutable length-1 thing you should have
> > to do a length 1 slice.  Otherwise its an index operation and you want
> > what is stored at the index, which is an immutable byte.
>
> OK. Though it's questionable even whether a slice of a mutable bytes
> object should return a mutable bytes object (as it is not a shared
> view). But as that is what PyBytes currently do it is certainly the
> easiest...

-Brett