PEP 3131: Supporting Non-ASCII Identifiers

[Bruno Desthuilliers]

Stefan Behnel a écrit :
> Martin v. Löwis schrieb:
> 
>>PEP 1 specifies that PEP authors need to collect feedback from the
>>community. As the author of PEP 3131, I'd like to encourage comments
>>to the PEP included below, either here (comp.lang.python), or to
>>python-3000 at python.org
>>
>>In summary, this PEP proposes to allow non-ASCII letters as
>>identifiers in Python. If the PEP is accepted, the following
>>identifiers would also become valid as class, function, or
>>variable names: Löffelstiel, changé, ошибка, or 売り場
>>(hoping that the latter one means "counter").
>>
>>I believe this PEP differs from other Py3k PEPs in that it really
>>requires feedback from people with different cultural background
>>to evaluate it fully - most other PEPs are culture-neutral.
>>
>>So, please provide feedback, e.g. perhaps by answering these
>>questions:
>>- should non-ASCII identifiers be supported? why?
>>- would you use them if it was possible to do so? in what cases?
> 
> 
> 
> To make it clear: this PEP considers "identifiers written with non-ASCII
> characters", not "identifiers named in a non-english language".

You cannot just claim that these are two totally distinct issues and get 
away with it. The fact is that not only non-english identifiers are a 
bad thing when it comes to sharing and cooperation, and it's obvious 
that non-ascii glyphs can only make things work - since it's obvious 
that people willing to use such a "feature" *wont* do it to spell 
english identifiers anyway.

> While the first is already allowed as long as the transcription uses only
> ASCII characters, the second is currently forbidden and is what this PEP is about.
> 
> Now, I am not a strong supporter (most public code will use English
> identifiers anyway) but we should not forget that Python supports encoding
> declarations in source files and thus has much cleaner support for non-ASCII
> source code than, say, Java. So, introducing non-ASCII identifiers is just a
> small step further.

I would certainly not qualify this as a "small" step.

> Disallowing this does *not* guarantee in any way that
> identifiers are understandable for English native speakers.

I'm not an English native speaker. And there's more than a subtle 
distinction between "not garantying" and "encouraging".

> It only guarantees
> that identifiers are always *typable* by people who have access to latin
> characters on their keyboard. A rather small advantage, I'd say.
> 
> The capability of a Unicode-aware language to express non-English identifiers
> in a non-ASCII encoding totally makes sense to me.

It does of course make sens (at least if you add support for non-english 
non-ascii translation of the *whole* language - keywords, builtins and 
the whole standard lib included). But it's still a very bad idea IMHO.