(original) (raw)
\[Nick Coghlan\]
> I'm OK with a target scope declaration construct having
\> lexical-scope-dependent behaviour - exactly what "nonlocal NAME" will
\> do depends on both the nature of the current scope,
\[Greg Ewing\]
Yes, but my point is that having an explicit "parentlocal" scope
declaration doesn't help to make anything more orthogonal,
because there's no way it can have \*exactly\* the same effect
as a comprehension's implicit parent-local scoping.
Sure it can - but I already explained that.
This is the analogy to "nonlocal" Nick is making: neither "nonlocal" nor "parentlocal" tell you which scope a declared name \_does\_ belong to. Instead they both say "it's not this scope" and specify algorithms you can follow to determine the scope to which the name does belong.
"parentlocal" isn't an accurate name because the owning scope may not be the parent block at all, and it may even be a synonym for "global". I think "by hand" translations of nested comprehensions into nested functions are clearer \_without\_ the "parentlocal" invention.- then you have to be explicit about what the context requires. Nick hates that because it isn't uniform. I like that because I don't want to pretend a non-uniform thing is uniform ;-) The only real use case here is synthesizing nested functions to implement comprehensions/genexps.
This is the analogy to "nonlocal" Nick is making: neither "nonlocal" nor "parentlocal" tell you which scope a declared name \_does\_ belong to. Instead they both say "it's not this scope" and specify algorithms you can follow to determine the scope to which the name does belong.
"parentlocal" isn't an accurate name because the owning scope may not be the parent block at all, and it may even be a synonym for "global". I think "by hand" translations of nested comprehensions into nested functions are clearer \_without\_ the "parentlocal" invention.- then you have to be explicit about what the context requires. Nick hates that because it isn't uniform. I like that because I don't want to pretend a non-uniform thing is uniform ;-) The only real use case here is synthesizing nested functions to implement comprehensions/genexps.
In other words, taking a comprehension and manually expanding
it into a function with parentlocal declarations wouldn't
give you something exactly equivalent to the original.
If that's the purpose of having an explicit parentlocal,
then it fails at that purpose.
You can add (a sufficient number of) parentlocal declarations to get the precise intended semantics. Then again, that can also be done today (without the "parentlocal" invention).
If that's \*not\* the purpose, then I'm not really sure what
the purpose is, because I can't think of a situation where
I'd choose to use parentlocal instead of nonlocal with an
explicit assignment in the outer scope.
For example, if the name is declared "global" in the outer scope, you'll get a compile-time error if you try to declare it "nonlocal" in the contained scope. "parentlocal" adjusts its meaning accordingly, becoming a synonym for "global" in that specific case.