[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