But in terms of explaining the text model, that
separation is important enough that
(1) We should be reluctant to strengthen the
"its really just ASCII" messages.
(2) It *may* be worth creating a virtual
split in the documentation.
I'm willing ot work on (2) if there is general consensus
that it would be a good idea. As a rough sketch, I
would change places like
http://docs.python.org/3/library/stdtypes.html#typebytes
from:
Bytes objects are immutable sequences of single bytes.
Since many major binary protocols are based on the ASCII
text encoding, bytes objects offer several methods that
are only valid when working with ASCII compatible data
and are closely related to string objects in a variety
of other ways.
to something more like:
Bytes objects are immutable sequences of single bytes.
A Bytes object could represent anything, and is
appropriate as the underlying storage for a sound sample
or image file.
Virtual subclass ASCIIStructuredBytes
====================================
One particularly common use of bytes is to represent
the contents of a file, or of a network message. In
these cases, the bytes will often represent Text
*in a specific encoding* and that encoding will usually
be a superset of ASCII. Rather than create and support
an ASCIIStructuredBytes subclass, Python simply added
support for these use cases straight to Bytes objects,
and assumes that this support simply won't be used when
when it does not make sense. For example, bytes literals
*could* be used to construct a sound sample, but the
literals will be far easier to read when they are used
to represent (encoded) ASCII text, such as "OPEN".