PEP 3131: Supporting Non-ASCII Identifiers

[Carsten Haese]

On Tue, 2007-05-15 at 06:44 -0700, George Sakkis wrote:
> After 175 replies (and counting), the only thing that is clear is the
> controversy around this PEP. Most people are very strong for or
> against it, with little middle ground in between. I'm not saying that
> every change must meet 100% acceptance, but here there is definitely a
> strong opposition to it. Accepting this PEP would upset lots of people
> as it seems, and it's interesting that quite a few are not even native
> english speakers.

While it is true that many of the PEP's opponents here on c.l.p are not
native English speakers, they are largely European or "Europeanized"
people. Many European people don't seem to realize that there are
entirely different cultures where people speak entirely different
languages written in entirely different writing systems, and English is
not widely spoken in many of those cultures. China comes to mind as but
one example of many.

Allowing people to use identifiers in their native language would
definitely be an advantage for people from such cultures. That's the use
case for this PEP. It's easy for Euro-centric people to say "just suck
it up and use ASCII", but the same people would probably starve to death
if they were suddenly teleported from Somewhere In Europe to rural China
which is so unimaginably different from what they know that it might
just as well be a different planet. "Learn English and use ASCII" is not
generally feasible advice in such cultures.

In my opinion, the principles of freedom and fostering global adoption
of Python, require that this PEP be accepted.

The objections for reasons of reduced code readability are valid, but I
think the open source community is good enough at regulating itself and
the community will predominantly *make the choice* to stick to
ASCII-only identifiers.

For programmers that are afraid of accidentally allowing non-ASCII
identifiers from patches, we might want to explore the possibility of
having Python's behavior switchable between ASCII and non-ASCII
identifiers, either by a compiler setting, environment variable, a "from
__future__" import, or similar mechanism.

Regards,

-- 
Carsten Haese
http://informixdb.sourceforge.net