On Thu, Sep 11, 2014 at 11:17:19AM +0900, Stephen J. Turnbull wrote:
It's all about convenience of representation for particular applications, end of story. A repr that obfuscates the content in the "ASCII segment" set of applications *might* be preferable for teaching applications, but I'm not even sure of that.
I think it is telling that hex editors, as a general rule, display byte data (i.e. the content of files) as both hex and ASCII. Real-world data is messy, and there are many cases where we want to hunt through an otherwise binary file looking for sequences of ASCII characters. Or visa versa. That's inherently mixing the concepts of text and bytes, but it needs to be done sometimes.
I am sad that the default representation of bytes displays ASCII, but I am also convinced that as regrettable as that choice is, the opposite choice would be even more regrettable. So I will be satisfied by an obvious way to display the hexified representation of a byte-string, even if that way is not repr().