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 >>[EMAIL PROTECTED] >> >>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. -- http://mail.python.org/mailman/listinfo/python-list