On 28 June 2018 at 08:31, Guido van Rossum <gu...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com