PEP 3131: Supporting Non-ASCII Identifiers

[Paul McGuire]

On May 14, 4:30 am, Nick Craig-Wood <n... at craig-wood.com> wrote:
>
> A variable called OHM etc!
> --
> Nick Craig-Wood <n... at craig-wood.com> --http://www.craig-wood.com/nick

Then can 'lambda' -> 'λ' be far behind?  (I know this is a keyword
issue, not covered by this PEP, but I also sense that the 'lambda'
keyword has always been ranklesome.)

In my own personal English-only experience, I've thought that it would
be helpful to the adoption of pyparsing if I could distribute class
name translations, since so much of my design goal of pyparsing is
that it be somewhat readable as in:

    integer = Word(nums)

is 'an integer is a word composed of numeric digits'.

By distributing a translation file, such as:

    Palabra = Word
    Grupo = Group
    etc.

a Spanish-speaker could write their own parser using:

    numero = Palabra(nums)

and this would still pass the "fairly easy-to-read" test, for that
user.  While my examples don't use any non-ASCII characters, I'm sure
the issue would come up fairly quickly.

As to the responder who suggested not mixing ASCII/Latin with, say,
Hebrew in any given identifier, this is not always possible.  On a
business trip to Israel, I learned that there are many terms that do
not have Hebrew correspondents, and so Hebrew technical literature is
sprinkled with English terms in Latin characters.  This is especially
interesting to watch being typed on a terminal, as the Hebrew
characters are written on the screen right-to-left, and then an
English word is typed by switching the editor to left-to-right mode.
The cursor remains in the same position and the typed Latin characters
push out to the left as they are typed.  Then typing in right-to-left
mode is resumed, just to the left of the Latin characters just
entered.

-- Paul