On 9/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > > On 9/25/07, Guido van Rossum <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
