[Python-3000] PEP 3137: Immutable Bytes and Mutable Buffer
Larry Hastings
larry at hastings.org
Fri Sep 28 03:32:29 CEST 2007
Guido van Rossum wrote:
> I think I've been convinced that b[0] should return an int in range(256).
This made me feel funny. I stared at this for a while:
b'a' != b'abcde'[0] ?!?
b'a'[0] != b'a' ?!?
Then I realized that making b[0] return an int simply makes bytes
objects behave less like strings, and more like tuples of integers:
( 97, ) != ( 97, 98, 99, 100, 101 )
( 97, )[0] != ( 97, )
Strings have always been the odd man out; no other sequence type has
this individual-elements-are-implicitly-sequences-too behavior.
So now bytes are straddling the difference between strings and the other
mapping types:
tuple:
to construct one with multiple elements: ( 97, 98, 99, 100, 101 )
elements aren't implicitly sequences: ( 97, ) != ( 97, 98, 99 )[0]
list:
to construct one with multiple elements: [ 97, 98, 99, 100, 101 ]
elements aren't implicitly sequences: [ 97, ] != [ 97, 98, 99 ][0]
bytes:
to construct one with multiple elements: b"abcde"
elements aren't implicitly sequences: b"a" != b"abcde"[0]
str:
to construct one with multiple elements: "abcde"
elements are implicity sequences: "a" == "abcde"[0]
So what should the bytes constructor take? We all already know it
should *not* take a string. (You must explicitly decode a string to get
a bytes object.) Clearly it should take an int in the proper range:
bytes(97) == b'a'
and a bytes object:
bytes(b'a') == b'a'
bytes(b'abcde') == b'abcde'
Like the tuple and list constructors, I think it should also attempt to
cast iterables into its type. So if you pass in an iterable, and the
iterable contains nothing but ints in the proper range, it should
produce a bytes object:
bytes( [ 97, 98, 99, 100, 101] ) == b'abcde'
Sorry if this is obvious to everybody; thinking through it helped me, at
least.
/larry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070927/050eed54/attachment.htm
More information about the Python-3000
mailing list