Statement local namespaces summary (was Re: python3: 'where' keyword)

Nick Coghlan ncoghlan at
Mon Jan 10 12:54:45 CET 2005

Duncan Booth wrote:
> Nick Coghlan wrote:
>>Grammar Change
>>   statement ::=    stmt_list NEWLINE | compound_stmt
>>   statement ::=    (stmt_list NEWLINE | compound_stmt) [local_namespace]
>>   local_namespace ::= "with" ":" suite
>>The code::
>><statement> with:
>>    <suite>
>>translates to::
>>def unique_name():
>>     <suite>
>>     <statement>
> Your proposed grammar change says that you need a newline after the 
> statement:

True, and not really what I intended. However, it does highlight the fact that 
statement lists haven't been considered in the discussion so far.

If statement lists are permitted, getting the right targets bound in the 
containing scope is going to be fun for things like this:

a = b = 2; c = 3; print a + b with:

(Probably not impossible though - e.g. it may be feasible to figure out all the 
bindings that have to happen and return an appropriate tuple from the inner 
scope for binding in the outer scope)

It might also be somewhat confusing as to exactly which statements are covered 
by the local scoping. (All of them would be, but you could be forgiven for 
assuming it was just the last one)

I think the following would work as a version of the grammar which permits local 
namespaces for statement lists:

   statement ::= (stmt_list (NEWLINE | local_namespace)) |
                 (compound_stmt [local_namespace])
   local_namespace ::= "with" ":" suite

Disallowing local namespaces for statement lists would suggest something like this:

   statement ::= (simple_stmt
                   (NEWLINE | ";" stmt_list NEWLINE | local_namespace)
                  ) |
                 (compound_stmt [local_namespace])
   local_namespace ::= "with" ":" suite

I'm pretty sure the permissive version is legal for the CPython parser, and I 
think the somewhat baroque structure I've used for the restrictive version makes 
it legal, too.

Disallowing local namespaces for statement lists might be a good place to start, 
since it gives an easier target for a first implementation.


Nick Coghlan   |   ncoghlan at   |   Brisbane, Australia

More information about the Python-list mailing list