As an aside to the discussion about "nonlocal", here are a couple of thoughts on backward compatibility.
For some of the proposed keywords, here's the number of occurrences of the keyword in the current standard library (not including comments and docstrings): nonlocal 0 0 use 2 2 using 3 3 reuse 0 4 free 8 8 outer 5 147 global 126 214 (I used 'tokenize' to do this; let me know if you'd like me to count other possibilities.) This may or may not be a good measure of the likely impact of adding a new keyword. At least it's something to think about. It also occurred to me that this new keyword doesn't necessarily have to break anything, if we are willing to tolerate a little hackery in the Python lexer and parser. The situation is a bit reminiscent of 'as' -- we were able to add 'as' to the 'import' statement as though 'as' were a keyword, without actually making 'as' a reserved word in all code. In this case, the usage of "nonlocal" (or whatever we choose) as a keyword never overlaps with its usage as a variable name. The parser could easily tell the difference by checking whether: - The keyword is at the beginning of a statement. - The keyword is immediately followed by an identifier. If both of these things are true, then the keyword is a nonlocal declaration. Otherwise, it can be treated as a variable name. I'm not saying this is necessarily a good idea; i just wanted to note that it was an available option. We might think about a schedule for phasing in the feature: Phase 1. If "nonlocal" is seen in code, issue a warning that it will become a keyword in a future version. Phase 2. Have the parser distinguish when "nonlocal" is intended as a keyword and when as a variable name. Phase 3. Make "nonlocal" an official reserved word. All of these phases are optional -- we could skip straight to 3, or do 1 and then 3, or stop at 2, etc. -- ?!ng _______________________________________________ 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