PEP 3131: Supporting Non-ASCII Identifiers

[MRAB]

On May 13, 8:49 pm, Michael Torrie <torr... at chem.byu.edu> wrote:
> On Sun, 2007-05-13 at 21:01 +0200, Stefan Behnel wrote:
> > For example, I could write
>
> >   def zieheDreiAbVon(wert):
> >       return zieheAb(wert, 3)
>
> > and most people on earth would not have a clue what this is good for. However,
> > someone who is fluent enough in German could guess from the names what this does.
>
> > I do not think non-ASCII characters make this 'problem' any worse. So I must
> > ask people to restrict their comments to the actual problem that this PEP is
> > trying to solve.
>
> I think non-ASCII characters makes the problem far far worse.  While I
> may not understand what the function is by it's name in your example,
> allowing non-ASCII characters makes it works by forcing all would-be
> code readers have to have all kinds of necessary fonts just to view the
> source code.  Things like reporting exceptions too.  At least in your
> example I know the exception occurred in zieheDreiAbVon.  But if that
> identifier is some UTF-8 string, how do I go about finding it in my text
> editor, or even reporting the message to the developers?  I don't happen
> to have that particular keymap installed in my linux system, so I can't
> even type the letters!
>
> So given that people can already transliterate their language for use as
> identifiers, I think avoiding non-ASCII character sets is a good idea.
> ASCII is simply the lowest denominator and is support by *all*
> configurations and locales on all developers' systems.
>
Perhaps there could be the option of typing and showing characters as
\uxxxx, eg. \u00FC instead of ü (u-umlaut), or showing them in a
different colour if they're not in a specified set.