[Python-Dev] PEP 460 reboot

[Jim J. Jewett]

Greg Ewing replied:

>> ... ASCII compatible binary data is a
>> *subset* of arbitrary binary data.

I 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.

(rough sketch below)

Ethan likes the idea, but points out that the term
"Virtual" is confusing here.

Alas, I'm not sure what the correct term is.  In
addition to "Go for it!" / "Don't waste your time",
I'm looking for advice on:

(A)  What word should I use instead of "Virtual"?
Imaginary?  Pretend?

(B)  Would it be good/bad/at least make the docs
easier to create an actual class (or alias)?

(C)  Same question for a pair of classes provided
only in the documentation, like example code.

(D)  What about an abstract class, or several?

e.g., replacing the XXX TODO of collections.abc.ByteString
with separate abstract classes for ByteSequence, String,
ByteString, and ASCIIByteString?

(ByteString already includes any bytes or bytearray instance,
so backward compatibility means the String suffix isn't
sufficient for an opt-in-by-instances class.)


> 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".


-jJ

-- 

If there are still threading problems with my replies, please 
email me with details, so that I can try to resolve them.  -jJ