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/
_______________________________________________
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
