PEP 3131: Supporting Non-ASCII Identifiers

[René Fleschenberg]

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",
"exception", "if" and so on if you did not know them before. It would be
extremely foolish not to do so. You do care about these names and you do
want to know their meaning if you want to write anything more in your
life than a 10-line throw-away script.

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

-- 
René