RetroSearch Browse

Wed May 18 17:57:46 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-May/111446.html

Greg Ewing wrote:
> Ethan Furman wrote:
> 
>> On the one hand we have the 'bytes are ascii data' type interface, and 
>> on the other we have the 'bytes are a list of integers between 0 - 
>> 255' interface.
> 
> I think the weird part is that there exists a literal for
> writing a byte array as an ascii string, and furthermore
> that it's the *only* kind of literal available for bytes.

That is the point I was trying to make -- thank you for stating it more 
clearly than I managed to.  :)

> Personally I think that the default literal syntax for
> bytes, and also the form produced by repr(), should have
> been something more neutral, such as hex,

Agreed.  It is surprising to extract an element out of bytes, and not 
end up with bytes, but with an int -- if the repr used something besides 
the plain ascii representation, this would not be an expectation.  For 
comparison, when one extracts an element out of a str one gets a str -- 
not the int representing the unicode code point.

> with the ascii form available for use when it makes sense.
> 
> 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

~Ethan~

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-May/111446.html below:

[Python-Dev] Python 3.x and bytes