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