[Nick Coghlan]>
actually made those semantics available as an explicit
> "parentlocal NAME" declaration ...:
>
> def _list_comp(_outermost_iter):
> parentlocal item
> _result = []
> for x in _outermost_iter:
> item = x
> _result.append(x)
> return _result
>
> _expr_result = _list_comp(items)
[Greg Ewing]
I'm not sure that's possible. If I understand correctly,
part of the definition of "parent local" is that "parent"
refers to the nearest enclosing *non-comprehension* scope,
to give the expected result for nested comprehensions.
If that's so, then it's impossible to fully decouple its
definition from comprehensions.
Nick's "parentlocal" does refer to the parent, but makes no distinction between synthesized and user-written functions. If the parent has a matching parentlocal declaration for the same name then the original really refers to the grandparent - and so on. Ultimately, it resolves to the closest enclosing scope in which the name is _not_ declared parentlocal. In that scope, a "nonlocal" or "global" declaration settles it if one appears, else the name is local to that scope.
So a nested comprehension would declare its assignment expression targets as parentlocal in its synthesized function, and in all the containing synthesized functions generated for containing comprehensions.
This appears in some strained ;-) way "natural" only because there is no explicit way to declare something "local" in Python. In just about any other language with closures and nested lexical scopes, comprehensions and generator expressions would have been implemented via nested functions that explicitly declared their "for" target names "local". and nothing else. The only change needed then for PEP 572 (b) semantics would be to declare assignment expression target names local (if their scope wasn't already known) in the closest containing non-synthesized block.
None of which really matters. The real question is which semantics are desired.