Cult-like behaviour [was Re: Kindness]

[Dan Sommers]

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.