Ethan Furman wrote: > On 01/07/2014 07:19 AM, David Robinow wrote: >> >> Python 3 grudgingly allows the "abomination" of byte strings (is that >> what they're called?) > > No, that is *not* what they're called. If you find any place in the > Python3 docs that does call them bytestrings please submit a bug report.
The name of the class is "bytes", but what they represent *is* a string of bytes, hence "byte-string". It's a standard computer science term for distinguishing strings of text from strings of bytes. > On 01/07/2014 08:12 AM, Steven D'Aprano wrote: >> People trying to port these libraries from 2.7 to 3 run into this >> problem, and it causes them grief. This little difference between bytes >> in 2.7 and bytes in 3.x is a point of friction which makes porting >> harder, and I'm trying to understand the reason for it. > > If I recall correctly the way it was explained to me: > > bytes (lists, arrays, etc.) is a container, and when a container is > indexed you get whatever the container held. If you slice the container > you get a smaller container with the appropriate items. (There's also a bytearray type, which is best considered as an array. Hence the name.) Why decide that the bytes type is best considered as a list of bytes rather than a string of bytes? It doesn't have any list methods, it looks like a string and people use it as a string. As you have discovered, it is an inconvenient annoyance that indexing returns an int instead of a one-byte byte-string. I think that, in hindsight, this was a major screw-up in Python 3. > bytes (and bytearrays) are containers of ints, so indexing returns an int. > One big problem with this whole scenario is > that bytes then lies about what it contains. (And I hate lies! [1]) > > Anyway, I believe that's the rationale behind the change. > > -- > ~Ethan~ > > [1] http://www.quickmeme.com/meme/3ts325 -- Steven -- https://mail.python.org/mailman/listinfo/python-list
