PEP 3131: Supporting Non-ASCII Identifiers

[Stefan Behnel]

René Fleschenberg wrote:
> Stefan Behnel schrieb:
>>> Now, very special environments (what I called "rare and isolated"
>>> earlier) like special learning environments for children are a different
>>> matter. It should be ok if you have to use a specially patched Python
>>> branch there, or have to use an interpreter option that enables the
>>> suggested behaviour. For general programming, it IMO is a bad idea.
>> Ok, let me put it differently.
>>
>> You *do not* design Python's keywords. You *do not* design the stdlib. You *do
>> not* design the concepts behind all that. You *use* them as they are. So you
>> can simply take the identifiers they define and use them the way the docs say.
>> You do not have to understand these names, they don't have to be words, they
>> don't have to mean anything to you. They are just tools. Even if you do not
>> understand English, they will not get in your way. You just learn them.
> 
> I claim that this is *completely unrealistic*. When learning Python, you
> *do* learn the actual meanings of English terms like "open",

Fine, then go ahead and learn their actual meaning in two languages (Python
and English). My point is: you don't have to. You only need to understand
their meaning in Python. Whether or not English can help here or can be useful
in your later life is completely off-topic.


>> But you *do* design your own software. You *do* design its concepts. You *do*
>> design its APIs. You *do* choose its identifiers. And you want them to be
>> clear and telling. You want them to match your (or your clients) view of the
>> application. You do not care about the naming of the tools you use inside. But
>> you do care about clarity and readability in *your own software*.
> 
> I do care about the naming of my tools. I care alot. Part of why I like
> Python is that it resisted the temptation to clutter the syntax up with
> strange symbols like Perl. And I do dislike the decorator syntax, for
> example.
> 
> Also, your distinction between "inside" and "your own" is nonsense,
> because the "inside" does heavily leak into the "own". It is impossible
> to write "your own software" with clarity and readability by your
> definition (i.e. in your native language). Any real Python program is a
> mix of identifiers you designed yourself and identifiers you did not
> design yourself. And I think the ones chosen by yourself are even often
> in the minority. It is not feasible in practice to just learn what the
> "other" identifiers do without understanding their names. Not for
> general programming. The standard library is already too big for that,
> and most real programs use not only the standard library, but also third
> party libraries that have English APIs.

Ok, I think the difference here is that I have practical experience with
developing that way and I am missing native identifiers in my daily work. You
don't have that experience and therefore do not feel that need. And you know
what? That's perfectly fine. I'm not criticising that at all. All I'm
criticising is that people without need for this feature are trying to prevent
those who need it and want to use it *where it is appropriate* from actually
getting this feature into the language.

Stefan