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).
However, what the option *does* enable is for a class of
users/developers to employ a broader range of characters if they *or
their teacher or employer* choose to do so.
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?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
