Nick Coghlan schrieb: > Martin v. Löwis wrote: >>> I think that's a pretty strong reason for making the new, more complex >>> behaviour optional. >> >> Thus making it simpler????? The more complex behavior still remains, >> to fully understand the language, you have to understand that behavior, >> *plus* you need to understand that it may sometimes not be present. > > It's simpler because any existing automated unit tests will flag > non-ascii identifiers without modification. Not only does it prevent > surreptitious insertion of malicious code, but existing projects don't > have to even waste any brainpower worrying about the implications of > Unicode identifiers (because library code typically doesn't care about > client code's identifiers, only about the objects the library is asked > to deal with).
I don't understand why existing projects would worry about the feature, for reasons different from the malicious code issue. If you don't want to waste brainpower on it, then just don't. > A free-for-all wasn't even proposed for strings and comments in PEP 263 > - why shouldn't we be equally conservative when it comes to > progressively enabling Unicode identifiers? Unfortunately, I don't understand this sentence. What is a "free-for-all", and why could it have been proposed by PEP 263, but wasn't? 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
