"Byte" type?

[John Nagle]

Steve Holden wrote:
> John Nagle wrote:
>> Steve Holden wrote:
>>> John Nagle wrote:
>>>> Benjamin Kaplan wrote:
>>>>> On Sun, Feb 15, 2009 at 11:57 AM, John Nagle <nagle at animats.com> wrote:
>>>>>
>> ...Re "bytes" not behaving as documented in 2.6:
>>
>>>>    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)"
>> ...
>>>> (Not true in Python 2.6
>>>> 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.
>>    Agreed.  But is this a 2.6 thing, making 2.6 incompatible with 3.0, or
>> what?  How will 3.x do it?  The PEP 3137 way, or the Python 2.6 way?
>>
>>    The way it works in 2.6 makes it necessary to do "ord" conversions
>> where they shouldn't be required.
>>
> Yes, the hack was to achieve a modicum of compatibility with 3.0 without
> having to turn the world upside down.
> 
> I haven't used 3.0 enough the say whether bytearray has been correctly
> implemented. But I believe the intention is that 3.0 should fully
> implement PEP 3137.

    If "bytes", a new keyword, works differently in 2.6 and 3.0, that was really
dumb.  There's no old code using "bytes".  So converting code to 2.6 means
it has to be converted AGAIN for 3.0.  That's a good reason to ignore 2.6 as
defective.

					John Nagle