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 ;-)
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
