[Python-3000] Support for PEP 3131

[Baptiste Carvello]

Martin v. Löwis a écrit :
> Baptiste Carvello schrieb:
>> Martin v. Löwis a écrit :
>>> I cannot imagine this scenario as realistic. It is certain
>>> realistic that you want to keep your own code base ASCII-only -
>>> what I don't understand why such a policy would extend to libraries
>>> that you use. If the interfaces of the library are non-ASCII, you
>>> will automatically notice; if it only has some non-ASCII
>>> identifiers inside, why would you bother?
>>>
>> well, for the same reason I prefer to use open source software:
>> because I can debug it in case of need, and because I can use it as
>> an inspiration if I need to write a similar program.
> 
> Ok, but why need you then *Python* to tell you that the file has
> non-ASCII identifiers? Just look inside the file, and see whether
> you like its source code. 
>
well, doing that for all code before using it is not practical. And finding out
you can't read the code at the precise time when you have a bug you need to
solve is a really bad surprise.

> It's not that non-ASCII identifiers
> *necessarily* make the file unmaintainable for your, they just
> do so when you cannot easily recognize or type the characters
> being used. 
>
true, but better safe than sorry :-)

> Also, that all identifiers are ASCII is not sufficient
> for you to be able to debug the program in case of need: it also
> needs to be commented well, and the comments also should be in
> a language you understand. 
>
comments are nice to have, but you can often figure out what the code does
without them. It's not like all code is heavily commented...

> Furthermore, it has been demonstrated
> that ASCII-only identifiers are no guarantee that you can actually
> understand the code, if they happen to be non-English in a convoluted
> way, e.g. through transliteration.
> 
This is the same as comments: if the identifier name is gibberish, you can still
figure out what it stands for from the context (OK, at that point, it starts
getting very unconfortable :-).

> So I don't see that an automatic detection of non-ASCII identifiers
> actually helps much in determining whether you can use the source
> code as inspiration. But even if you wanted to enforce a strict
> "ASCII-only" policy, I don't see why you need Python to *reject*
> identifiers outside ASCII - a warning would be surely enough to
> indicate to you that your policy was violated.
> 
indeed, but I doubt a warning would be acceptable as a default policy, given how
annoying they are. So there would still need to be a configuration option to
disable (resp. enable) the warning. Also note that a warning would not solve the
security problems others have discussed, because it would only be shown after
the code has been executed.

> Regards,
> Martin
> 

Cheers,
Baptiste

PS: I think I'm going to reduce my participation in this thread, as I don't have
many new thoughts to add. I'm not convinced that non-ACSII identifiers allowed
by default is the way to go, but I'm not 100% sure otherwise, so count me as a
-0 on that.