[Python-3000] PEP 3131 accepted

["Martin v. Löwis"]

> Much of my concerns could be addressed through the use of commandline,
> environment variable, or in-source code definitions of what are
> allowable identifier characters.  Generally, in-source definitions (like
> the coding: directive) are the most flexible, but are the biggest pain
> for editors and IDEs (which may want to verify every identifier as it is
> being typed, etc.).

Not sure (anymore) what problem you are trying to solve, but it might be
that the coding directive already *is* the solution. If you want to
constrain characters that you can use in a single source file, adding
a coding directive will automatically impose such a constraint (namely,
to the characters available in the encoding).

In particular, if you set the encoding to us-ascii, you have restricted
your source file to ASCII only.

> If people can agree on a method for specifying, 'ascii only', 'ascii +
> character sets X, Y, Z', and it actually becomes an accepted part of the
> proposal, gets implemented, etc., I will grumble to myself at home, but
> I will stop trying to raise a stink here.

I think you can stop now - this is supported as a side effect of
PEP 263, and implemented for years.

> My "fear" is that being able to prove (to myself and others) that the
> code I am looking at does what it should do.  As you say, maybe I will
> never see non-ascii source in my life.  But even if I don't, I know some
> of my users will, and to not be American-centric, I need to continue to
> provide them with "tools that don't suck" (which will likely necessitate
> testing using non-ascii identifiers).

I think the PEP 263 machinery allows for great flexibility hear.

Additional tools can be implemented, of course, and will be produced
if there is a demand for them (e.g. post-commit hooks for versioning
systems).

Regards,
Martin