[Python-3000] Support for PEP 3131 (original) (raw)

Josiah Carlson jcarlson at uci.edu
Fri May 25 18:41:53 CEST 2007

"Martin v. Löwis" <martin at v.loewis.de> wrote:

>> People should not have to read long system configuration pages >> just to run the program that they intuitively wrote correctly >> right from the start. > > You mean that 5% of users who run into code written using non-ascii > identifiers will find this sufficiently burdensome to force the 95% of > ascii users to use additional verification and checking tools to make > sure that they are not confronted with non-ascii identifiers? I don't > find that a reasonable tradeoff for the majority of (non-unicode) users. I think I lost track of what problem you are trying to solve: is it the security issue, or is the the problem Ping stated ("you cannot know the full lexical rules by heart anymore"). If it is the latter, I don't understand why the 95% ascii users need to run additional verification and checking tools. If they don't know the full language, they won't use it - why should they run any checking tools?

Say that I have an ascii codebase that I've been happily using (and I have been getting warnings/errors/whatever whenever non-ascii code is found during runtime, so I know it is pure). But I want to use a 3rd party package that offers additional functionality*. I drop this package into my tree, add the necessary imports and...

ImportError: non-ascii identifier used without -U option

Huh, apparently this 3rd party package uses non-ascii identifiers. If I wanted to keep my codebase ascii-only (a not unlikely case), I can choose to either look for a different package, look for a variant of this package with only ascii identifiers, or attempt to convert the package myself (a tool that does the unicode -> ascii transliteration process would make this smoother).

For those who don't care about ascii or non-ascii identifiers, they will likely already have an environment variable or site.py modification that offers all unicode characters that they want, and they will never see this message.

If it is the security issue, I don't see why a warning wouldn't address the concerns of these users just as well.

It's partially a security issue, but that's only 1 of the 5 reasons that Ka-Ping pointed out. But yes, I want to see a message and I want the software to halt and tell me that it found something that may be an issue. And I want this to automatically happen every time I run Python

More information about the Python-3000 mailing list