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. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
