On 1/14/2014 1:11 PM, Jim J. Jewett wrote:
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".
I rather like this. Consider opening a tracker issue. -- Terry Jan Reedy _______________________________________________ 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
