PEP 3131: Supporting Non-ASCII Identifiers

["Martin v. Löwis"]

> The only objection that comes to mind is that adding such support may
> make some distinct identifiers visually indistinguishable.  IIRC the DNS
> system has had this problem, leading to much phishing abuse.

This is a commonly-raised objection, but I don't understand why people
see it as a problem. The phishing issue surely won't apply, as you
normally don't "click" on identifiers, but rather type them. In a
phishing case, it is normally difficult to type the fake character
(because the phishing relies on you mistaking the character for another
one, so you would type the wrong identifier).

People have mentioned that this could be used to obscure your code - but
there are so many ways to write obscure code that I don't see a problem
in adding yet another way.

People also mentioned that they might mistake identifiers in a regular,
non-phishing, non-joking scenario, because they can't tell whether the
second letter of MAXLINESIZE is a Latin A or Greek Alpha. I find that
hard to believe - if the rest of the identifier is Latin, the A surely
also is Latin, and if the rest is Greek, it's likely an Alpha. The issue
is only with single-letter identifiers, and those are most common
as local variables. Then, it's an Alpha if there is also a Beta and
a Gamma as a local variable - if you have B and C also, it's likely A.

> I don't necessarily think that the objection is strong enough to reject
> the idea -- programmers using non-ASCII symbols would be responsible for
> the consequences of their character choice.

Indeed.

Martin