PEP 3131: Supporting Non-ASCII Identifiers

Steven D'Aprano steven at REMOVE.THIS.cybersource.com.au
Sun May 13 22:46:17 EDT 2007


On Sun, 13 May 2007 17:59:23 -0700, Paul Rubin wrote:

> Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:
>> > It certainly does apply, if you're maintaining a program and someone
>> > submits a patch.  In that case you neither click nor type the
>> > character.  You'd normally just make sure the patched program passes
>> > the existing test suite, and examine the patch on the screen to make
>> > sure it looks reasonable.  The phishing possibilities are obvious.
>> 
>> Not to me, I'm afraid. Can you explain how it works? A phisher might be
>> able to fool a casual reader, but how does he fool the compiler into
>> executing the wrong code?
> 
> The compiler wouldn't execute the wrong code; it would execute the code
> that the phisher intended it to execute.  That might be different from
> what it looked like to the reviewer.

How? Just repeating in more words your original claim doesn't explain a 
thing.

It seems to me that your argument is, only slightly exaggerated, akin to 
the following:

"Unicode identifiers are bad because phishers will no longer need to 
write call_evil_func() but can write call_ƎvĬľ_func() instead."

Maybe I'm naive, but I don't see how giving phishers the ability to 
insert a call to ƒunction() in some module is any more dangerous than 
them inserting a call to function() instead.

If I'm mistaken, please explain why I'm mistaken, not just repeat your 
claim in different words.


-- 
Steven.



More information about the Python-list mailing list