"Byte" type?

[John Nagle]

Martin v. Löwis wrote:
>>> Please don't call something dumb that you don't fully understand. It's
>>> offenses the people who have spent lots of time developing Python --
>>> personal, unpaid and voluntary time!

    Some of the people involved are on Google's payroll.

>> Crying out;  "Please do not criticise me, I am doing it for free!" does
>> not justify delivering sub standard work - that is the nature of the
>> open source process - if you lift your head and say or do something,
>> there are bound to be some objections - some thoughtful and valid,
>> and others merely carping.  Being sensitive about it serves no purpose.
> 
> Still, John *clearly* doesn't understand what he observes, so asking him
> not to draw conclusions until he does understand is not defending
> against criticism.
> 
>> This is not a helpful response - on the surface JN has a point - If
>> you have to go through two conversions, then 2.6 does not achieve
>> what it appears to set out to do.  So the issue is simple:
>>
>> - do you have to convert twice?
> 
> Depends on how you write your code. If you use the bytearray type
> (which John didn't, despite his apparent believe that he did),
> then no conversion additional conversion is needed.

     According to PEP 3137, there should be no distinction between
the two for read purposes.  In 2.6, there is.  That's a bug.

> Likewise, if you only use byte (not bytearray) literals, without
> accessing individual bytes (e.g. if you only ever read and write
> them, or pass them to the struct module), 2to3 will do the right
> thing.
> 
>> - If yes - why? - as he says - there exists no prior code,
>>   so there seems to be no reason not to make it identical
>>   to 3.0
> 
> Sure there is. Making the bytes type and the str type identical
> in 2.x gives the easiest way of porting. Adding bytes as a separate
> type would have complicated a lot of things.
> 
> Regards,
> Martin

    No, it's broken.  PEP 3137 says one thing, and the 2.6 implementation
does something else.  So code written for 2.6 won't be ready for 3.0.
This defeats the supposed point of 2.6.

					John Nagle