PEP 3131: Supporting Non-ASCII Identifiers

[Steven D'Aprano]

I've made various comments to other people's responses, so I guess it is 
time to actually respond to the PEP itself.

On Sun, 13 May 2007 17:44:39 +0200, Martin v. Löwis wrote:

> PEP 1 specifies that PEP authors need to collect feedback from the
> community. As the author of PEP 3131, I'd like to encourage comments to
> the PEP included below, either here (comp.lang.python), or to
> python-3000 at python.org
> 
> In summary, this PEP proposes to allow non-ASCII letters as identifiers
> in Python. If the PEP is accepted, the following identifiers would also
> become valid as class, function, or variable names: Löffelstiel, changé,
> ошибка, or 売り場 (hoping that the latter one means "counter").
> 
> I believe this PEP differs from other Py3k PEPs in that it really
> requires feedback from people with different cultural background to
> evaluate it fully - most other PEPs are culture-neutral.
> 
> So, please provide feedback, e.g. perhaps by answering these questions:
> - should non-ASCII identifiers be supported? why? - would you use them
> if it was possible to do so? in what cases?

It seems to me that none of the objections to non-ASCII identifiers are 
particularly strong. I've heard many accusations that they will introduce 
"vulnerabilities", by analogy to unicode attacks in URLs, but I haven't 
seen any credible explanations of how these vulnerabilities would work, 
or how they are any different to existing threats. That's not to say that 
there isn't a credible threat, but if there is, nobody has come close to 
explaining it.

I would find it useful to be able to use non-ASCII characters for heavily 
mathematical programs. There would be a closer correspondence between the 
code and the mathematical equations if one could write Δ(µ*π) instead of 
delta(mu*pi). 

(Aside: I wonder what the Numeric crowd would say about this?)




-- 
Steven.