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

[Nick Coghlan]

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