Non-ASCII in identifiers

["Martin v. Löwis"]

Terry Reedy wrote:

> While sympathizing with this notion, I have hitherto opposed it on the
> basis that this would lead to code that could only be read by people within
> each language group.  But, rereading your idea, I realize that this
> objection would be overcome by a reader that displayed for each Unicode
> char (codepoint?) not its native glyph but a roman transliteration. 

I personally consider this objection irrelevant. Yes, it is desirable
that portable libraries use only pronouncable (in English) identifiers.
However, that is no justification for the language to make a policy
decision that all source code in the language needs to use pronouncable
identifiers. Instead, the author of each piece of code needs to make
a decision what kind of identifiers to use. Some people (e.g. children)
don't care a bit if somebody 20km away can read their source code, let
alone somebody 10000km away - those far-away people will never get
to see the code in the first place.

So I doubt there is much need for transliterating source code viewers.
At the same time, it might be a fun project to do.

> Some writing systems also have different number digits, which could also be
> used natively and tranliterated.  A Unicode Python could also use a set of
> user codepoints as an alternate coding of keywords for almost complete
> nativification.  I believe the math symbols are pretty universal (but could
> be educated if not).

Now, this is different story. To implement this, the Python parser needs
to be changed to contain locale information, and one carefully has to
make an implementation so that the same code will run the same way
independent on the locale in which it is executed. This requires that
information about all locales is included in all installations, which
is expensive to maintain.

In addition, alternate keywords might not help so much, since real
integration into the natural language would also require to change
the order of identifiers and keywords - something that I consider
unimplementable.

Regards,
Martin