Aside: OK, Guido, ya got me.
I have a separate screed recounting the reasons for my apostasy, but
that's probably not interesting any more. I'll send it to individuals
on request.
> 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.
True. I think the right message is is "Unless you know why you
*desperately* want this, not only don't you need it, but using it is
the Python equivalent of skydiving without a parachute."
N.B. Don't take the metaphor as an insult. I think it's become clear
that those who "desperately want this" not only use parachutes, they
pack their own. No need to worry about them.
> (2) It *may* be worth creating a virtual
> split in the documentation.
Please don't. All we need to tell naive users is:
Look at the structure of the bytes. If that structure is "text",
convert to str using .decode(). Please don't use bytes.
If that structure isn't text, you're in a specialist domain, and
it's your problem. Many structured uses of bytes use ASCII-
encoded keywords: we provide bytes methods for handling them, but
you *must* be aware that these methods *cannot* distinguish "bytes
representing text encoded as ASCII" from "any old bytes". Be
warned: They will happily -- and silently -- corrupt the latter.
Make sure you respect the higher-level structure of your data when
using them.
> 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
This is going quite the wrong direction, I think. The only people who
should care about "Text *in a specific encoding* and that encoding
will usually be a superset of ASCII" are codec writers, and by now
writing those is a very rare task. Everybody else uses ASCII keywords
in a simple formal language.
> *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".
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
