On Tue, 17 Jul 2018 08:48:55 +1000, Chris Angelico wrote: > That said, though, the fact that indexing a byte string yields an int > instead of a one-byte string is basically unable to be changed now ...
Agreed. > ... and IMO it'd be better to be consistent with text strings than > with bytearray ... Disagreed. Given an arbitrary byte string, you can't know whether it's semantically text or semantically an array of bytes. (Sometimes a good byte array is just a byte array?) In the past, I've done plenty of work with "strings" (in the generic sense) of octets to/from wire-level protocols. It would have been much easier had Python *not* tried to pretend they were text, and *not* rendered some of the bytes as their ASCII equivalent and some of the bytes as hex escapes (especially in the cases that some of the bytes happened to be 0x58, 0x78, 0x5c, or in range(0x30, 0x3a)). > ... I'm not sure how many of the core devs agree that b'spam'[1] ought > to be b'p' rather than 112, but I'd say they all agree that it's too > late to change it. Curmudgeonly C programmer that I am, b'p' *is* 112. ;-) Quick: how long is the byte array that displays as '\xff'? Too easy? What about '\0xff' and '0\xff'? FWIW, Erlang, a language all but designed to read/write wire level protocols, prints any array of integers less than 256 as a(n ASCII) text string. It never *mixes* integers and characters, but often picks the wrong one. -- https://mail.python.org/mailman/listinfo/python-list
