[Python-Dev] Python 3.x and bytes (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Thu May 19 12:37:27 CEST 2011
- Previous message: [Python-Dev] Python 3.x and bytes
- Next message: [Python-Dev] Python 3.x and bytes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, 19 May 2011 17:49:47 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote:
It's a mental model problem. People try to think of bytes as equivalent to 2.x str and that's just wrong, wrong, wrong. It's far closer to array.array('c'). Strings are basically unique in returning a length 1 instance of themselves for indexing operations. For every other sequence type, including tuples, lists and arrays, slicing returns a new instance of the same type, while indexing will typically return something different. Now, we definitely didn't help matters by keeping so many of the default behaviours of bytes() and bytearray() coupled to ASCII-encoded text, but that was a matter of practicality beating purity: there really are a lot of wire protocols out there that are ASCII based.
I think "practicality beating purity" should have been extended to getitem as well. I have almost never had a use for treating a bytestring as a sequence of integers, while treating a bytestring as a sequence of one-byte strings is very common.
(and, as you say, if you want a sequence of integers you can already use array.array() which gives you more flexibility as to the width and signedness of integers)
Regards
Antoine.
- Previous message: [Python-Dev] Python 3.x and bytes
- Next message: [Python-Dev] Python 3.x and bytes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]