PEP 3131: Supporting Non-ASCII Identifiers

Stefan Behnel stefan.behnel-n05pAM at web.de
Mon May 14 05:04:36 EDT 2007


Alex Martelli schrieb:
> Aldo Cortesi <aldo at nullcube.com> wrote:
> 
>> Thus spake Steven D'Aprano (steven at REMOVE.THIS.cybersource.com.au):
>>
>>> If you're relying on cursory visual inspection to recognize harmful code,
>>> you're already vulnerable to trojans.
>> What a daft thing to say. How do YOU recognize harmful code in a patch
>> submission? Perhaps you blindly apply patches, and then run your test suite on
>> a quarantined system, with an instrumented operating system to allow you to
>> trace process execution, and then perform a few weeks worth of analysis on the
>> data?
>>
>> Me, I try to understand a patch by reading it. Call me old-fashioned.
> 
> I concur, Aldo.  Indeed, if I _can't_ be sure I understand a patch, I
> don't accept it -- I ask the submitter to make it clearer.
> 
> Homoglyphs would ensure I could _never_ be sure I understand a patch,
> without at least running it through some transliteration tool.  I don't
> think the world of open source needs this extra hurdle in its path.

But then, where's the problem? Just stick to accepting only patches that are
plain ASCII *for your particular project*. And if you want to be sure, put an
ASCII encoding header in all source files (which you want to do anyway, to
prevent the same problem with string constants).

The PEP is only arguing to support this decision at a per-project level rather
than forbidding it at the language level. This makes sense as it moves the
power into the hands of those people who actually use it, not those who
designed the language.

Stefan



More information about the Python-list mailing list