[Python-3000] Support for PEP 3131

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

 - Josiah

 * Or I copy and paste code from the Python Cookbook, a blog, etc.

More information about the Python-3000 mailing list