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