"Martin v. Löwis" <[EMAIL PROTECTED]> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
