John Nagle wrote:
> Benjamin Kaplan wrote:
>> On Sun, Feb 15, 2009 at 11:57 AM, John Nagle <na...@animats.com> wrote:
>>
>>> Benjamin Peterson wrote:
>
>> Because b'x' is NOT a bytearray. It is a bytes object. When you
>> actually use
>> a bytearray, it behaves like you expect.
>>>>> type(b'x')
>> <class 'bytes'>
>>>>> type(bytearray(b'x'))
>> <class 'bytearray'>
>>>>> ba = bytearray(b'abc')
>>>>> ba[0] + ba[1]
>> 195
>
> That's indeed how Python 2.6 works. But that's not how
> PEP 3137 says it's supposed to work.
>
> Guido:
>
> "I propose the following type names at the Python level:
>
> * bytes is an immutable array of bytes (PyString)
> * bytearray is a mutable array of bytes (PyBytes)"
>
> ...
>
> "Indexing bytes and bytearray returns small ints (like the bytes type in
> 3.0a1, and like lists or array.array('B'))."
> (Not true in Python 2.6 - indexing a "bytes" object returns a "bytes"
> object with length 1.)
>
> "b1 + b2: concatenation. With mixed bytes/bytearray operands, the return
> type is
> that of the first argument (this seems arbitrary until you consider how
> += works)."
> (Not true in Python 2.6 - concatenation returns a bytearray in both cases.)
>
> Is this a bug, a feature, a documentation error, or bad design?
>
It's a feature. In fact all that was done to accommodate easier
migration to 3.x is easily shown in one statement:
>>> str is bytes
True
>>>
So that's why bytes works the way it does in 2.6 ... hence my contested
description of it as an "ugly hack". I am happy to withdraw "ugly", but
I think "hack" could still be held to apply.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--
http://mail.python.org/mailman/listinfo/python-list
