> 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.