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. 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. 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. 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. 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. Regards, Martin _______________________________________________ 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