PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

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

> So, introducing non-ASCII identifiers is just a
> small step further. Disallowing this does *not* guarantee in any way that
> identifiers are understandable for English native speakers. 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.

I would certainly not qualify that as "rather small". There have been  
quite a few times where I had to change some public code. If this code had  
been written in a character set that did not exist on my keyboard, the  
only possibility would have been to copy/paste every identifier I had to  
type. Have you ever tried to do that? It's actually quite simple to test  
it: just remove on your keyboard a quite frequent letter ('E' is a good  
candidate), and try to update some code you have at hand. You'll see that  
it takes 4 to 5 times longer than writing the code directly, because you  
always have to switch between keyboard and mouse far too often. In  
addition to the unnecessary movements, it also completely breaks your  
concentration. Typing foreign words transliterated to english actually  
does take longer than typing "proper" english words, but at least, it can  
be done, and it's still faster than having to copy/paste everything.

So I'd say that it would be a major drawback for code sharing, which - if  
I'm not mistaken - is the basis for the whole open-source philosophy.
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"