PEP 3131: Supporting Non-ASCII Identifiers

["Martin v. Löwis"]

> You could say the same about Python standard library and keywords then.
> Shouldn't these also have to be translated? One can even push things a
> little further: I don't know about the languages used in the countries
> you mention, but for example, a simple construction like 'if <condition>
> <do something>' will look weird to a Japanese (the Japanese language has
> a "post-fix" feel: the equivalent of the 'if' is put after the
> condition). So why enforce an English-like sentence structure?

The Python syntax does not use an English-like sentence structure.
In English, a statement follows the pretty strict sequence of subject,
predicate, object (SPO). In Python, statements don't have a subject;
some don't even have a verb (e.g. assignments).

Regardless, this PEP does not propose to change the syntax of the
language, because doing so would cause technical problems - unlike
the proposed PEP, which does not cause any technical problems to
the language implementation whatsoever (and only slight technical
problems to editors, which aren't worse than the ones cause by
PEP 263).

> You have a point here. When learning to program, or when programming for
> fun without any intention to do something serious, it may be better to
> have a language supporting "native" characters in identifiers. My
> problem is: if you allow these, how can you prevent them from going
> public someday?

You can't, and you shouldn't. What you can prevent is that the code
enters *your* project. I cannot see why you want to censor what code
other people publish.

Regards,
Martin