[Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part) (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Jun 30 03:56:37 EDT 2018

On 28 June 2018 at 08:31, Guido van Rossum <guido at python.org> wrote:

So IIUC you are okay with the behavior described by the PEP but you want an explicit language feature to specify it?

I don't particularly like adding a parentlocal statement to the language, because I don't think it'll be generally useful. (We don't have goto in the language even though it could be used in the formal specification of if, for example. :-) But as a descriptive mechanism to make the PEP's spec clearer I'm fine with it. Let's call it _parentlocal for now. It would work a bit like nonlocal but also different, since in the normal case (when there's no matching nonlocal in the parent scope) it would make the target a local in that scope rather than trying to look for a definition of the target name in surrounding (non-class, non-global) scopes. Also if there's a matching global in the parent scope, _parentlocal itself changes its meaning to global. If you want to push a target through several level of target scopes you can do that by having a _parentlocal in each scope that it should push through (this is needed for nested comprehensions, see below). Given that definition of _parentlocal, in first approximation the scoping rule proposed by PEP 572 would then be: In comprehensions (which in my use in the PEP 572 discussion includes generator expressions) the targets of inline assignments are automatically endowed with a _parentlocal declaration, except inside the "outermost iterable" (since that already runs in the parent scope). There would have to be additional words when comprehensions themselves are nested (e.g. [[a for a in range(i)] for i in range(10)]) since the PEP's intention is that inline assignments anywhere there end up targeting the scope containing the outermost comprehension. But this can all be expressed by adding _parentlocal for various variables in various places (including in the "outermost iterable" of inner comprehensions). I'd also like to keep the rule prohibiting use of the same name as a comprehension loop control variable and as an inline assignment target; this rule would also prohibit shenanigans with nested comprehensions (for any set of nested comprehensions, any name that's a loop control variable in any of them cannot be an inline assignment target in any of them). This would also apply to the "outermost iterable". Does this help at all, or did I miss something?

Yep, it does, and I don't think you missed anything.

Using "__parentlocal" to indicate "parent local scoping semantics apply here" still gives the concept a name and descriptive shorthand for use in pseudo-code expansions of assignment expressions in comprehensions, without needing to give it an actually usable statement level syntax, similar to the way we use "_expr_result" and "_outermost_iter" to indicate references that in reality are entries in an interpreter's stack or register set, or else a pseudo-variable that doesn't have a normal attribute identifier.

And if anyone does want to make the case for the syntax being generally available, they don't need to specify how it should work - they just need to provide evidence of cases where it would clarify code unrelated to the PEP 572 use case.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list