PEP 3131: Supporting Non-ASCII Identifiers

Stefan Behnel stefan.behnel-n05pAM at web.de
Mon May 14 06:17:36 EDT 2007


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.

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.

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

It should at least be an available option to use this feature.

Stefan



More information about the Python-list mailing list