[issue4199] add shorthand global and nonlocal statements

[Jeremy Hylton]

Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

I guess there's some question about whether the syntax in the PEP was
considered carefully when it was approved.  If so, I'm not sure that
we want to re-open the discussion.  On the other hand, it's been a
long time since the PEP was approved and we do have a moratorium on
language changes, so it doesn't hurt to slow things down.

I'd argue that the intent of the PEP is pretty clear.  You can take
any assignment statement where the LHS doesn't have subscripts, put a
nonlocal or global in front of it, and it means that all those
assignments are to global/nonlocal variables.

Jeremy

On Wed, Feb 24, 2010 at 4:20 AM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
>> I also notice that the Grammar in the PEP is more complicated:
>> nonlocal_stmt ::=
>>     "nonlocal" identifier ("," identifier)*
>>                ["=" (target_list "=")+ expression_list]
>>   | "nonlocal" identifier augop expression_list
>>
>> The Grammar in the patch is:
>> +global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
>> +nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]
>>
>> It appears that the PEP is trying to support:
>>
>> nonlocal x = y = z = 1
>> nonlocal a, b = c, d = 1
>
> It also tries to support augmented assignment; however I'm not sure what the semantics of that should be.
>
> Further, there is an ambiguity if too much freedom is allowed: what about
>
>   global x = 1, y
>
> Is it declaring a global "x" and assigning a tuple, or declaring a global "x" and a global "y"?
>
>> If we're going to support the PEP as written, I think we need to
>> modify Global() and Nonlocal() to look exactly like Assign(), but add
>> an extra check to verify that all of the expressions in the targets
>> are Name, List, or Tuple.  You'd probably want to check this at the
>> time you are generating the AST, so that you're not stuck with some
>> extra state in the compiler traversal about whether you are generating
>> code for a Global() or an Assign().
>
> I would not support List or Tuple as targets.  Same basic problem as
> above, and I don't see a use case.
>
> I see two possibilities for the actual syntax:
>
> 1) global *either* supports multiple identifiers, *or* one identifier
> and an assignment.
>
> 2) global always supports multiple identifiers, each with an optional
> assignment; tuples need parentheses.
>
> In both cases, I would keep it simple and not allow multiple targets or
> augmented assignment.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4199>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4199>
_______________________________________