[Python-3000] PEP 3131 accepted (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Thu May 24 20:45:34 CEST 2007

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

More information about the Python-3000 mailing list