PEP 3131: Supporting Non-ASCII Identifiers

[Bruno Desthuilliers]

Stefan Behnel a écrit :
> Eric Brunel wrote:
>> On Mon, 14 May 2007 11:00:29 +0200, Stefan Behnel
>>> Any chance there are still kanji-enabled programmes around that were
>>> not hit
>>> by the bomb in this scenario? They might still be able to help you get
>>> the
>>> code "public".
>> Contrarily to what one might think seeing the great achievements of
>> open-source software, people willing to maintain public code and/or make
>> it evolve seem to be quite rare. If you add burdens on such people -
>> such as being able to read and write the language of the original code
>> writer, or forcing them to request a translation or transliteration from
>> someone else -, the chances are that they will become even rarer...
> 
> Ok, but then maybe that code just will not become Open Source. There's a
> million reasons code cannot be made Open Source, licensing being one, lack of
> resources being another, bad implementation and lack of documentation being
> important also.
> 
> But that won't change by keeping Unicode characters out of source code.

Nope, but adding unicode glyphs support for identifiers will only make 
things worse, and we (free software authors/users/supporters) 
definitively *don't* need this.

> Now that we're at it, badly named english identifiers chosen by non-english
> native speakers, for example, are a sure way to keep people from understanding
> the code and thus from being able to contribute resources.

Broken English is certainly better than German or French or Italian when 
it comes to sharing code.

> I'm far from saying that all code should start using non-ASCII characters.
> There are *very* good reasons why a lot of projects are well off with ASCII
> and should obey the good advice of sticking to plain ASCII. But those are
> mainly projects that are developed in English and use English documentation,
> so there is not much of a risk to stumble into problems anyway.
> 
> I'm only saying that this shouldn't be a language restriction, as there
> definitely *are* projects (I know some for my part) that can benefit from the
> clarity of native language identifiers (just like English speaking projects
> benefit from the English language).

As far as I'm concerned, I find "frenglish" source code (code with 
identifiers in French) a total abomination. The fact is that all the 
language (keywords, builtins, stdlib) *is* in English. Unless you 
address that fact, your PEP is worthless (and even if you really plan to 
do something about this, I still find it a very bad idea for reasons 
already exposed).

The fact is also that anyone at least half-serious wrt/ CS will learn 
technical English anyway. And, as other already pointed, learning 
technical English is certainly not the most difficult part when it comes 
to programming.

> And yes, this includes spelling native
> language identifiers in the native way to make them easy to read and fast to
> grasp for those who maintain the code.

Yes, fine. So we end up with a code that's a mix of English (keywords, 
builtins, stdlib, almost if not all third-part libs) and native 
language. So, while native speakers will still have to deal with 
English, non-native speakers won't be able to understand anything. Talk 
about a great idea...