[Python-3000] Support for PEP 3131

Nick Coghlan ncoghlan at gmail.com
Fri May 25 15:55:01 CEST 2007

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?


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-3000 mailing list