[Python-3000] Immutable bytes -- looking for volunteer (original) (raw)

Brett Cannon brett at python.org
Wed Sep 26 02:55:47 CEST 2007

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

More information about the Python-3000 mailing list