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
--
http://mail.python.org/mailman/listinfo/python-list
