[Python-ideas] Inline assignments using "given" clauses

[Tim Peters]

[Steven D'Aprano <steve at pearwood.info>]
>>> ...
>>> average = 0
>>> smooth_signal = [(average := (1-decay)*average + decay*x) for x in signal]
>>> assert average == smooth_signal[-1]

[Tim]
>> The scope issues are logically independent of assignment-expression
>> spelling, but it's a pretty safe guess Nick is opposed to that example
>> ever "just working" regardless of spelling, while PEP 572 doesn't
>> currently support it anyway.


[Nick Coghlan <ncoghlan at gmail.com>]
> I'm personally fine with that example working

"Just working" meant "exactly as written".  "Regardless of spelling"
meant whether binding is spelled via ":=", "given", "as", "where",
"let ... in ...' "->", ..


> if there's an explicit nonlocal declaration on "average" in the nested
> scope - it's Guido that objected to requiring the explicit scoping
> declaration to access that behaviour.

I suspect, but don't know, that Guido would like that example to "just
work" because it _looks like_ it should "just work".  There's no
visible function involved, and _needing_ to add scope declarations to
make it work is pretty much inexplicable unless the user first learns
more than most users "should" need to learn about how it's
implemented.

If so, no technical argument will change his mind - and especially not
one based on "but the implementation today doesn't do that already".
Recall that Python had no lexically nested scoping at first?  If he
wanted to _make_ users learn about nested lexical scopes to use Python
features that don't _appear_ to use it, Python would have had it from
the start ;-)

I'd be happy enough with needing an explicit declaration too, but am
_happiest_ with what I'm guessing Guido's view is.


> For the implicit version, my request is that any PEP proposing the idea of
> parent local scoping be held to the standard of *actually drafting the patch
> for the language specification*,

Of course.


> rather than handwaving away the hard problems that it creates
> (i.e. what to do at class scope,

I finally looked at class scope and quickly decided it makes no sense
there (a comprehension at class scope has no access to the class
scope, so "same scope in the comprehension as in its immediately
containing block" is incoherent in that case).


> what to do when multiple generators expressions reference the same
> nonlocal name,

Then, as you said, they access the same nonlocal name.  What of it?
What if two generator functions reference (or even rebind) the same
nonlocal name?  What's unclear about that?

If you were happy with explicit scope declarations, then exactly the
same thing would happen as if the user were forced to explicitly
declare the scopes chosen for them.


> what to do with nested comprehensions,

Again, if you were happy with explicit scope declarations, then
exactly the same ...

Where are the docs explaining how nested comprehensions work today?  I
haven't seen any.  If any such exist, I'd bet nothing about them needs
to be changed.  If none such exist, I don't see a need to write any
just for this PEP.  How do nested expressions of any kind work?  Same
thing.

The only thing the suggestion changes is the scope of assignment
expression targets in synthetic functions created to implement
comprehensions.  That has nothing at all to do with the possibility of
nesting, or with the structure of nesting.  Why do you think it does -
or might?


> how to expand comprehensions using this kind of scoping to their statement
> form in a context independent way).

I've already explained why I view that as a non-issue (making a
tedious manual process a relative handful of users undertake once in
their life for self-education purposes slightly less tedious has
approximately no value to me - and, to the contrary, the "context
dependent" bits they may have to learn would make it _more_
educational).  If that's a show-stopper for you, so be it.