[Python-3000] Support for PEP 3131

["Martin v. Löwis"]

>> Indeed, PEP 3131 gives a predictable identifier character set.
>> Adding per-site options to change the set of allowable characters
>> makes it less predictable.
> 
> Not in practice.
> 
> Today, identifiers are drawn from [A-Za-z0-9], which is a fairly small set.
> 
> Under the current PEP 3131 proposal, they will be drawn from a much
> larger set.  There won't normally be many more letters actually used
> in any given program, but there will be many more that are possible
> (with very low probability).

It's true that nobody could realistically enumerate all characters that
would be allowed in identifiers. However, it is still practically
easily predictable whether a given string makes an identifier
*for a speaker of that language it is in*. The rule still is
"letters, digits, and the underscore".

It's certainly possible to come up with obscure cases where people
will guess incorrectly whether they are valid syntax, but it is
always possible to deliberately obfuscate code. Except for the
malicious-user case (which apparently needs to be addressed),
I don't see a problem with the existence of obscure cases.

> By allowing site modifications, the rule becomes:
> 
> It will use ASCII.

Not universally - only on that site. I don't know what rule is
in force on my buddy's machine, so predicting it becomes harder.

> There are potential exceptions for code that gets shared beyond local
> groups without ASCII-fication, but this is a strict subset of the
> "unreadable" code used under "anything-goes".  Distribution without
> ASCIIfication is discouraged (by the extra decision required at
> installation time), users have explicit notice (by accepting it at
> install time), and the expanded charset is still a tiny fraction of
> what PEP3131 currently proposes (you can accept French characters
> withough accepting Chinese ideographs).

I just put wording in the PEP that makes it clear that, whatever
the problem, a global flag is not an acceptable solution.

Regards,
Martin