<br><br><div><span class="gmail_quote">On 11/5/06, <b class="gmail_sendername">Ka-Ping Yee</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As an aside to the discussion about "nonlocal", here are a couple of<br>thoughts on backward compatibility.<br><br>For some of the proposed keywords, here's the number of occurrences<br>of the keyword in the current standard library (not including comments
<br>and docstrings):<br><br> nonlocal 0 0<br> use 2 2<br> using 3 3<br> reuse 0 4<br> free 8 8<br> outer 5 147<br> global 126 214
<br><br>(I used 'tokenize' to do this; let me know if you'd like me to count<br>other possibilities.)<br><br>This may or may not be a good measure of the likely impact of adding<br>a new keyword. At least it's something to think about.
<br><br>It also occurred to me that this new keyword doesn't necessarily<br>have to break anything, if we are willing to tolerate a little<br>hackery in the Python lexer and parser. The situation is a bit<br>reminiscent of 'as' -- we were able to add 'as' to the 'import'
<br>statement as though 'as' were a keyword, without actually making<br>'as' a reserved word in all code.<br><br>In this case, the usage of "nonlocal" (or whatever we choose) as<br>a keyword never overlaps with its usage as a variable name. The
<br>parser could easily tell the difference by checking whether:<br><br> - The keyword is at the beginning of a statement.<br> - The keyword is immediately followed by an identifier.<br><br>If both of these things are true, then the keyword is a nonlocal
<br>declaration. Otherwise, it can be treated as a variable name.<br><br>I'm not saying this is necessarily a good idea; i just wanted to<br>note that it was an available option. We might think about a<br>schedule for phasing in the feature:
<br><br> Phase 1. If "nonlocal" is seen in code, issue a warning<br> that it will become a keyword in a future version.<br><br> Phase 2. Have the parser distinguish when "nonlocal" is
<br> intended as a keyword and when as a variable name.<br><br> Phase 3. Make "nonlocal" an official reserved word.<br><br>All of these phases are optional -- we could skip straight to 3,<br>or do 1 and then 3, or stop at 2, etc.
</blockquote><div><br>Any new keyword would require a __future__ statement which automatically implies a warning in the version that introduces the __future__ statement. Then the next version makes it a keyword and the __future__ statement redundant. So the transition to a new keyword is already established.