PEP 3131: Supporting Non-ASCII Identifiers

[Eric Brunel]

On Tue, 15 May 2007 17:35:11 +0200, Stefan Behnel  
<stefan.behnel-n05pAM at web.de> wrote:
> Eric Brunel wrote:
>> On Tue, 15 May 2007 15:57:32 +0200, Stefan Behnel
>>> In-house developers are rather for this PEP as they see the advantage  
>>> of
>>> expressing concepts in the way the "non-techies" talk about it.
>>
>> No: I *am* an "in-house" developer. The argument is not
>> public/open-source against private/industrial. As I said in some of my
>> earlier posts, any code can pass through many people in its life, people
>> not having the same language. I dare to say that starting a project
>> today in any other language than english is almost irresponsible: the
>> chances that it will get at least read by people not talking the same
>> language as the original coders are very close to 100%, even if it
>> always stays "private".
>
> Ok, so I'm an Open-Source guy who happens to work in-house. And I'm a
> supporter of PEP 3131. I admit that I was simplifying in my round-up. :)
>
> But I would say that "irresponsible" is a pretty self-centered word in  
> this
> context. Can't you imagine that those who take the "irresponsible"  
> decisions
> of working on (and starting) projects in "another language than English"  
> are
> maybe as responsible as you are when you take the decision of starting a
> project in English, but in a different context? It all depends on the  
> specific
> constraints of the project, i.e. environment, developer skills, domain,  
> ...
>
> The more complex an application domain, the more important is clear and
> correct domain terminology. And software developers just don't have  
> that. They
> know their own domain (software development with all those concepts,  
> languages
> and keywords), but there is a reason why they develop software for those  
> who
> know the complex professional domain in detail but do not know how to  
> develop
> software. And it's a good idea to name things in a way that is  
> consistent with
> those who know the professional domain.
>
> That's why keywords are taken from the domain of software development and
> identifiers are taken (mostly) from the application domain. And that's  
> why I
> support PEP 3131.

You keep eluding the question: even if the decisions made at the project  
start seem quite sensible *at that time*, if the project ends up  
maintained in Korea, you *will have* to translate all your identifiers to  
something displayable, understandable and typable by (almost) anyone,  
a.k.a ASCII-English... Since - as I already said - I'm quite convinced  
that any application bigger than the average quick-n-dirty throwable  
script is highly likely to end up in a different country than its original  
coders', you'll end up losing the time you appeared to have gained in the  
beginning. That's what I called "irresponsible" (even if I admit that the  
word was a bit strong...).

Anyway, concerning the PEP, I've finally "put some water in my wine" as we  
say in French, and I'm not so strongly against it now... Not for the  
reasons you give (so we can continue our flame war on this ;-) ), but  
mainly considering Python's usage in a learning context: this is a valid  
reason why non-ASCII identifiers should be supported. I just wish I'll get  
a '--ascii-only' switch on my Python interpreter (or any other means to  
forbid non-ASCII identifiers and/or strings and/or comments).
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in  
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"