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

[Greg Ewing]

Tim Peters wrote:
> Because you never _need_ to use an assignment expression to write a
> listcomp/genexp.

This whole discussion started because someone wanted a way
to bind a temporary result for use *within* a comprehension.
Those use cases don't require leakage.

> Otherwise it's essentially impossible to explain why:
> 
>     total = 0
>     sums = [total := total + value for value in data]
>     assert sums[-1] == total
> 
> "blows up", despite that its intent is obvious,unless you first
> explain to a user how the listcomp is implemented via an invisible
> synthetic function created by magic, inside of which `total`  has
> nothing to do with the `total` they see on the first line.

It's no harder to explain that than it is to explain
why

    x = 42
    y = [x * x for x in range(5)]
    print(x)

prints 42 rather than whatever value was last bound to
the x in the comprehension.

Seems to me it would be easier to explain that *all* names
bound within a comprehension are local to the comprehension,
than to have to say that some are and some aren't.

-- 
Greg



> UnboundLocalError - WTF?
> 
> That's why leaking "is good".  It works both directions:  the outer
> name leaks _into_ the body too, not just _out_ of it.  Things that
> "look like" they should obviously work do work then, and a user can
> remain blissfully unaware of the implementation.. Of course you can
> also find cases in which it's not wanted.
> 
> If it doesn't leak the kind of use shown above can't be done at all
> via listcomps (at least not straightforwardly).
> 
> If it does leak, the subset of cases where leaking is unwanted _of_
> the subset of cases in which a listcomp//genexp uses an assignment
> expression at all are indeed inconvenienced.
> 
> So - surprise!  It's a tradeoff, something we've never faced before ;-)