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

Josiah Carlson jcarlson at uci.edu
Fri May 25 08:59:59 CEST 2007

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

>> People who want to use the feature would have to know that it is only >> present if you turn it on. It's like saying "you can use hexadecimal >> integer literals, but you have to turn them on". This wouldn't work: >> people try to use them, find out that it won't work, and assume >> that it's not supported. > > Are we going to stop offering informational error messages to people? > Because an informational error message could go a long way towards > helping people to understand what is going on.

I don't think there is precedence in Python for such an informational error message. It is not pythonic to give an error in the case "I know what you want, and I could easily do it, but I don't feel like doing it, read these ten pages of text to learn more about the problem".

ImportError("non-ascii names used without proper charset definition")

They hop online, enter that phrase into google, and (hopefully) get a page at python.org that says something like...

If you have received this error, and merely want to get your source to run, use: python --charset=unicode ...

If you know the character set of the source you want to run (which can be discovered by checking the output of scripts/charset.py), you can use: python --charset= ...

If you would like to make this the default, add a PY_CHARSET environment variable with a comma separated list of allowable character sets (ascii is always included).

If you would like to programmatically change the allowable character set, use the .

The most similar case is the future import statement, where we in fact report an error even though it's typically clear what the desired meaning of the program is. However, this statement is only meant as a transitional measure, with a view of eventually changing the error into making the future behavior the default. I understand that you want that to be a permanent error, and this I object to.

That's fine, but it's not just me that has this opinion and desire for ascii default behavior.

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.

More information about the Python-3000 mailing list