PEP 3131: Supporting Non-ASCII Identifiers

[rurpy at yahoo.com]

On May 16, 8:49 pm, Gregor Horvath <g... at gregor-horvath.com> wrote:
> r... at yahoo.com schrieb:
> >> 2) Create a way to internationalize the standard library (and possibly
> >> the language keywords, too). Ideally, create a general standardized way
> >> to internationalize code, possibly similiar to how people
> >> internationalize strings today.
> >
> > Why?  Or more acurately why before adopting the PEP?
> > The library is very usable by non-english speakers as long as
> > there is documentation in their native language.  It would be
>
> Microsoft once translated their VBA to foreign languages.
> I didn't use it because I was used to "English" code.
> If I program in mixed cultural contexts I have to use to smallest
> dominator. Mixing the symbols of the programming language is confusing.

Yup, I agree wholeheartedly.  So do almost all
the other people who have responded in this thread.
In public code, open source code, code being worked
on by people from different countries, English is almost
always the best choice.

Nothing in the PEP interferes with or prevents this.
The PEP only allows non-ascii indentifiers, when they
are appropriate: in code that is unlikely to be ever
be touched by people who don't know that language.
(Obviously any language feature can be misused
but peer-pressure, documentation, and education
have been very effective in preventing such misuse.
There is no reason they shouldn't be effective
here too.)

And yes, some code will be developed in a single
language enviroment and then be found to be useful
to a wider audience.  It's not the end of the world.
It is no worse than when code written with a single
language UI that is becomes public -- it will get
fixed so that it meets the standards for a internationaly
collaborative project.  Seems to me that replacing
identifiers with english ones is fairly trivial
isn't it?  One can identify identifiers by parsing
the program and replacing them from a prepared table
of replacements?  This seems much easier than fixing
comments and docstrings which need to be done by
hand.  But the comment/docstring problem exists now
and has nothing to do with the PEP.

> Long time ago at the age of 12 I learned programming using English
> Computer books. Then there were no German books at all. It was not easy.
> It would have been completely impossible if our schools system would not
> have been wise enough to teach as English early.
>
> I think millions of people are handicapped because of this.
> Any step to improve this, is a good step for all of us. In no doubt
> there are a lot of talents wasted because of this wall.

I agree that anyone who wants to be a programmer is
well advised to learn English.  I would also advise
anyone who wants to be a programmer to go to college.
But I have met very good programmers who were not
college graduates and although I don't know any non-
english speakers I am sure there are very good programers
who don't know English.

There is a big difference between encouraging someone
to do something, and taking steps to make them do
something.

A lot of the english-only retoric in this thread seems
very reminiscent of arguments a decade+ ago regarding
wide characters and unicode, and other i18n support.
"Computing is ascii-based, we don't need all this
crap, and besides, it doubles the memory used by strings!
English is good enough".  Except of course that it wasn't.

When technology demands that people adapt to it, it looses.
When technology adapts to the needs of people, it wins.

The fundamental question is whether languages designers,
or the people writing the code, should be the ones to
decide what language identifiers are most appropriate
for their program.  Do language designers, all of whom
are English speakers, have the wisdom to decide for
programmers all over the world, and for years to come,
that they must learn English to use Python effectively?
And if they do, will the people affected agree, or
will they choose a different language?