[Fwd: In Python 2.6, bytes is str]
This does make it look rather as though bytes == str was a decision whose consequences weren't fully appreciated before implementation. Was this horror anticipated? regards Steve -------- Original Message -------- Subject: In Python 2.6, bytes is str Date: Sun, 05 Oct 2008 22:30:17 -0700 From: Bryan Olson <fakeaddress@nowhere.org> Organization: at&t http://my.att.net/ To: python-list@python.org Newsgroups: gmane.comp.python.general Python 3 has the 'bytes' type, which the string type I've long wanted in various languages. Among other advantages, it is immutable, and therefore bytes objects can be dict keys. There's a mutable version too, called "bytearray". In Python 2.6, the name 'bytes' is defined, and bound to str. The 2.6 assignment presents some pitfalls. Be aware. Consider constructing a bytes object as: b = bytes([68, 255, 0]) In Python 3.x, len(b) will be 3, which feels right. In Python 2.6, len(b) will be 12, because b is the str, '[68, 255, 0]'. I'm thinking I should just avoid using 'bytes' in Python 2.6. If there's another Python release between 2.6 and 3.gold, I'd advocate removing the pre-defined 'bytes', or maybe defining it as something else. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
On Sun, Oct 5, 2008 at 11:43 PM, Steve Holden <steve@holdenweb.com> wrote:
This does make it look rather as though bytes == str was a decision whose consequences weren't fully appreciated before implementation.
Well, you could say that about almost any change.
Was this horror anticipated?
I didn't anticipate it.
regards Steve
-------- Original Message -------- Subject: In Python 2.6, bytes is str Date: Sun, 05 Oct 2008 22:30:17 -0700 From: Bryan Olson <fakeaddress@nowhere.org> Organization: at&t http://my.att.net/ To: python-list@python.org Newsgroups: gmane.comp.python.general
Python 3 has the 'bytes' type, which the string type I've long wanted in various languages. Among other advantages, it is immutable, and therefore bytes objects can be dict keys. There's a mutable version too, called "bytearray".
In Python 2.6, the name 'bytes' is defined, and bound to str. The 2.6 assignment presents some pitfalls. Be aware.
Consider constructing a bytes object as:
b = bytes([68, 255, 0])
In Python 3.x, len(b) will be 3, which feels right.
In Python 2.6, len(b) will be 12, because b is the str, '[68, 255, 0]'.
I'm thinking I should just avoid using 'bytes' in Python 2.6. If there's another Python release between 2.6 and 3.gold, I'd advocate removing the pre-defined 'bytes', or maybe defining it as something else.
I think it needs to be made clear that bytes is there for type compatibility (e.g., ``isinstance(ob, bytes)``). And the bytes literals work how you would expect. What I would like to know if there are any other gotchas beyond the constructor as all of the other uses act as you would expect. -Brett
Brett Cannon wrote:
What I would like to know if there are any other gotchas beyond the constructor as all of the other uses act as you would expect.
Mainly that indexing returns one character substrings instead of ints. The bytes type is there as an indicator of what bytes literals represent in 2.6 - yes, that's not the same thing as what they represent in 3.0, and no, you don't magically get the benefits of byte/str separation in the 2.x series. Maybe that could be caveat'ed better somewhere in the docs, but it does reflect the reality of the situation. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On Sun, Oct 5, 2008 at 11:43 PM, Steve Holden <steve@holdenweb.com> wrote:
This does make it look rather as though bytes == str was a decision whose consequences weren't fully appreciated before implementation.
Was this horror anticipated?
It was well understood that the bytes "type" in 2.6 and the bytes type in 3.0 would behave quite different. Attempts to come up with a separate bytes type that behaved more like its 3.0 counterpart were doomed, because there just are too many places where the usage was ambiguous. We should probably have written a PEP about this just to prevent the discussion from being repeated all over again in this thread. The only two anticipated *reasonable* uses in 2.6 were the bytes literal (b'abc') and tests for isinstance(x, bytes), which are flags for 2to3 to keep these usages as bytes, not str. I have no intention of rolling this back. It isn't compatible with 3.0, but then, 2.6 and 3.0 aren't in general meant to be compatible -- 2.6 is a stepping stone, but that's not the same thing. It is backwards compatible with prior versions because it is new in 2.6, so it shouldn't break old code. I have only limited sympathy for people who don't read documentation in this case. --Guido
-------- Original Message -------- Subject: In Python 2.6, bytes is str Date: Sun, 05 Oct 2008 22:30:17 -0700 From: Bryan Olson <fakeaddress@nowhere.org> Organization: at&t http://my.att.net/ To: python-list@python.org Newsgroups: gmane.comp.python.general
Python 3 has the 'bytes' type, which the string type I've long wanted in various languages. Among other advantages, it is immutable, and therefore bytes objects can be dict keys. There's a mutable version too, called "bytearray".
In Python 2.6, the name 'bytes' is defined, and bound to str. The 2.6 assignment presents some pitfalls. Be aware.
Consider constructing a bytes object as:
b = bytes([68, 255, 0])
In Python 3.x, len(b) will be 3, which feels right.
In Python 2.6, len(b) will be 12, because b is the str, '[68, 255, 0]'.
I'm thinking I should just avoid using 'bytes' in Python 2.6. If there's another Python release between 2.6 and 3.gold, I'd advocate removing the pre-defined 'bytes', or maybe defining it as something else.
-- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
-- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
It was well understood that the bytes "type" in 2.6 and the bytes type in 3.0 would behave quite different. Attempts to come up with a separate bytes type that behaved more like its 3.0 counterpart were doomed, because there just are too many places where the usage was ambiguous. We should probably have written a PEP about this just to prevent the discussion from being repeated all over again in this thread.
The only two anticipated *reasonable* uses in 2.6 were the bytes literal (b'abc') and tests for isinstance(x, bytes), which are flags for 2to3 to keep these usages as bytes, not str.
Full ack! I replies this to the op on the general Python list: --- I guess you got the intention of the bytes alias wrong. It's partly my fault because I didn't document the bytes alias. We are well aware that the bytes alias in 2.6 isn't fully compatible with the bytes type in 3.0. The bytes alias isn't MEANT to be compatible, too. :) At first I wanted to backport the bytes type from 3.0 to 2.6. But it was too many work and the implications of yet another types were too complex. So I just added the alias in order to help people with writing forward compatible code like e.g. isinstance(egg, bytes). Summa summarum the bytes alias was added for documentary purpose and to aid the 2to3 transition of code where 'str' is ambiguous. --
I have no intention of rolling this back. It isn't compatible with 3.0, but then, 2.6 and 3.0 aren't in general meant to be compatible -- 2.6 is a stepping stone, but that's not the same thing. It is backwards compatible with prior versions because it is new in 2.6, so it shouldn't break old code. I have only limited sympathy for people who don't read documentation in this case.
Maybe the documentation isn't clear enough what purpose the bytes alias serves? I spent 5 minutes with the docs but I wasn't able to find a good explanation of the bytes alias Christian
Christian Heimes wrote:
Guido van Rossum wrote: [...]
I have no intention of rolling this back. It isn't compatible with 3.0, but then, 2.6 and 3.0 aren't in general meant to be compatible -- 2.6 is a stepping stone, but that's not the same thing. It is backwards compatible with prior versions because it is new in 2.6, so it shouldn't break old code. I have only limited sympathy for people who don't read documentation in this case.
Maybe the documentation isn't clear enough what purpose the bytes alias serves? I spent 5 minutes with the docs but I wasn't able to find a good explanation of the bytes alias
Yes, I think all that's really needed is a clarification in the documentation. Just so people expect slightly kooky behavior of the kind originally noted. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
participants (5)
-
Brett Cannon -
Christian Heimes -
Guido van Rossum -
Nick Coghlan -
Steve Holden