PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Mon, 14 May 2007 11:00:29 +0200, Stefan Behnel  
<stefan.behnel-n05pAM at web.de> wrote:

> Eric Brunel wrote:
>> On Sun, 13 May 2007 21:10:46 +0200, Stefan Behnel
>> <stefan.behnel-n05pAM at web.de> wrote:
>> [snip]
>>> Now, I am not a strong supporter (most public code will use English
>>> identifiers anyway)
>>
>> How will you guarantee that? I'm quite convinced that most of the public
>> code today started its life as private code earlier...
>
> Ok, so we're back to my original example: the problem here is not the
> non-ASCII encoding but the non-english identifiers.

As I said in the rest of my post, I do recognize that there is a problem  
with non-english identifiers. I only think that allowing these identifiers  
to use a non-ASCII encoding will make things worse, and so should be  
avoided.

> If we move the problem to a pure unicode naming problem:
>
> How likely is it that it's *you* (lacking a native, say, kanji keyboard)  
> who
> ends up with code that uses identifiers written in kanji? And that you  
> are the
> only person who is now left to do the switch to an ASCII transliteration?
>
> 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...
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"