On 01/14/2014 10:11 AM, Jim J. Jewett wrote:
But in terms of explaining the text model, that
separation is important enough that
(2) It *may* be worth creating a virtual
split in the documentation.
I think (2) is a great idea.
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".
I find the Virtual subclass in the title to be confusing, but I otherwise it's great. We should have that even if we do
add formatting to bytes, as that message is even more important then.
--
~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
