<br><br><div><span class="gmail_quote">On 11/5/06, <b class="gmail_sendername">Ka-Ping Yee</b> &lt;<a href="mailto:python@zesty.ca">python@zesty.ca</a>&gt; 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 &quot;nonlocal&quot;, 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>&nbsp;&nbsp;&nbsp;&nbsp;nonlocal&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0<br>&nbsp;&nbsp;&nbsp;&nbsp;use&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2<br>&nbsp;&nbsp;&nbsp;&nbsp;using&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<br>&nbsp;&nbsp;&nbsp;&nbsp;reuse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4<br>&nbsp;&nbsp;&nbsp;&nbsp;free&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8<br>&nbsp;&nbsp;&nbsp;&nbsp;outer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp; 147<br>&nbsp;&nbsp;&nbsp;&nbsp;global&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;126&nbsp;&nbsp;&nbsp;&nbsp; 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.&nbsp;&nbsp;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.&nbsp;&nbsp;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 &quot;nonlocal&quot; (or whatever we choose) as<br>a keyword never overlaps with its usage as a variable name.&nbsp;&nbsp;The
<br>parser could easily tell the difference by checking whether:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;- The keyword is at the beginning of a statement.<br>&nbsp;&nbsp;&nbsp;&nbsp;- 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.&nbsp;&nbsp;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.&nbsp;&nbsp;We might think about a<br>schedule for phasing in the feature:
<br><br>&nbsp;&nbsp;&nbsp;&nbsp;Phase 1.&nbsp;&nbsp;If &quot;nonlocal&quot; is seen in code, issue a warning<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;that it will become a keyword in a future version.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;Phase 2.&nbsp;&nbsp;Have the parser distinguish when &quot;nonlocal&quot; is
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;intended as a keyword and when as a variable name.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;Phase 3.&nbsp;&nbsp;Make &quot;nonlocal&quot; 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.&nbsp; Then the next version makes it a keyword and the __future__ statement redundant.&nbsp; So the transition to a new keyword is already established.
<br><br>-Brett<br></div><br></div><br>