[Python-3000] Support for PEP 3131

[Rauli Ruohonen]

On 6/3/07, Stephen J. Turnbull <turnbull at sk.tsukuba.ac.jp> wrote:
> Merely to define those is non-trivial, and it is absolutely out
> of the question to expect that the average Python user will know
> what the character set "strictly-conforms-to-UTR39-restrictions-
> allows-confusables" is.

This is a bit of a strawman, as most of the time the charset would
be ascii or everything, which are much easier concepts. Point
taken about trying anything more complex, as the reader will
generally no longer understand that anyway. A special-purpose tool
can handle the complex cases much better.

> ease of use is "globally restrict to what my students can read =
> ASCII + Japanese".

I prefer your first definition of ease of use:

> Ease of use of audited code is trivial; turn the checks off.

This along with your another idea sounds fairly good, actually:

> The reason I favor the single command line flag (perhaps even
> restricted to the binary choice of compatibility ASCII vs. PEP
> 3131 Unicode) is as a transition strategy.

The KISS way of having a single flag for either ASCII or PEP 3131
(if the even simpler way of only PEP 3131 is too simple) should
take care of most (all?) of the use cases, and nobody's head will
explode. If it's this simple, then it's not a problem to have
it on the command line, and my suggestion is unnecessary.

> I do not agree with Ka-Ping inter alia that there are bogeymen
> under the bed,

Looks like the only ones who do agree want pure ASCII, so a binary
option is sufficient. You could also argue that it's a choice of
old behavior and new behavior, and anything else is unnecessary.
You might even use "from __future__ import unicode_identifiers"
instead of a command line flag, if you view it like that.

> but then I live in Japan, and there *is* no "under
> the bed" (we sleep on mats on the floor<wink>).

ちなみに私も日本で布団で寝たことがあります<wink>

> I think it's quite reasonable to provide a non-invasive, *simple*
> auditing facility for those who want it.

Emphasis on simple, indeed. If you start adding more complex
auditing systems, then it would make sense for the files to declare
which specification they conform to.

> When you're talking about security holes, the burden of proof
> should *not* be on the paranoid

The default doesn't really matter much. It's simple to use
"#!/usr/bin/env python -U" or whatever in scripts, whether that
option selects PEP 3131 or ascii.

> As James Knight says, the "configure the world in one file"
> strategy that jJ and I were batting around is a bit nuts, but it
> might not be a bad strategy for configuring a loadable auditing
> codec or external utility; I don't think that's wasted mental
> effort at all.

True, but such details have clearly gone beyond a "*simple*
auditing facility" and sound like a solution looking for a problem.