[Python-3000] Support for PEP 3131

[Josiah Carlson]

"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=<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 <charset modification module> .


> 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.


 - Josiah