[Python-3000] Backward compatibility for "nonlocal"

Brett Cannon brett at python.org
Mon Nov 6 20:33:00 CET 2006


On 11/5/06, Ka-Ping Yee <python at zesty.ca> wrote:
>
> 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.


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.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061106/2730b3b4/attachment.html 


More information about the Python-3000 mailing list