Ethan Furman wrote:
Greg Ewing wrote:
As for
--> some_other_var[3] == b'd'
there ought to be a literal for specifying an integer
using an ascii character, so you could say something like
if some_other_var[3] == c'd':
which would be equivalent to
if some_other_var[3] == ord(b'd')
but without the overhead of computing the value each time
at run time.
Given that we can't change the behavior of b'abc'[1], that would be
better than what we have.
+1
Here's another thought, that perhaps is not backwards-incompatible...
some_var[3] == b'd'
At some point, the bytes class' __eq__ will be called -- is there a
reason why we cannot have
1) a check to see if the bytes instance is length 1
2) a check to see if
i) the other object is an int, and
2) 0 <= other_obj < 256
3) if 1 and 2, make the comparison instead of returning NotImplemented?
This makes sense to me -- after all, the bytes class is an array of ints
in range(256); it is a special case, but doesn't feel any more special
than passing an int into bytes() giving a string of that many null
bytes; and it would get rid of the, in my opinion ugly, idiom of
some_var[i:i+1] == b'd'
It would also not require a new literal syntax.
~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
