<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 9 May 2018 at 03:06, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>So the way I envision it is that *in the absence of a nonlocal or global declaration in the containing scope*, := inside a comprehension or genexpr causes the compiler to assign to a local in the containing scope, which is elevated to a cell (if it isn't already). If there is an explicit nonlocal or global declaration in the containing scope, that is honored.<br><br></div>Examples:<br><br></div><div>  # Simplest case, neither nonlocal nor global declaration<br></div>  def foo():<br></div>      [p := q for q in range(10)]  # Creates foo-local variable p<br></div>      print(p)  # Prints 9<br><br></div><div>  # There's a nonlocal declaration<br></div>  def bar():<br></div><div>      p = 42  # Needed to determine its scope<br></div>      def inner():<br></div>          nonlocal p<br></div>          [p := q for q in range(10)]  # Assigns to p in bar's scope<br></div>      inner()<br></div>      print(p)  # Prints 9<br><br></div><div>  # There's a global declaration<br></div>  def baz():<br></div><div>      global p<br></div>      [p := q for q in range(10)]<br></div>  baz()<br></div>  print(p)  # Prints 9<br><br></div>All these would work the same way if you wrote list(p := q for q in range(10)) instead of the comprehension.<br></div></blockquote><div><br></div><div>How would you expect this to work in cases where the generator expression isn't immediately consumed? If "p" is nonlocal (or global) by default, then that opens up the opportunity for it to be rebound between generator steps. That gets especially confusing if you have multiple generator expressions in the same scope iterating in parallel using the same binding target:<br><br></div><div>    # This is fine<br></div><div>    gen1 = (p for p in range(10))<br></div><div><div><div>    gen2 = (p for p in gen1)<br></div><div>    print(list(gen2))<br><br></div><div><div></div></div>    # This is not (given the "let's reintroduce leaking from comprehensions" proposal)<br></div><div>    p = 0<br></div><div>    gen1 = (p := q for q in range(10))<br></div><div><div><div>    gen2 = (p, p := q for q in gen1)<br></div><div></div></div></div><div>    print(list(gen2))<br></div><br>It also reintroduces the original problem that comprehension scopes solved, just in a slightly different form:<br><br></div><div>    # This is fine<br></div><div>    for x in range(10):<br></div><div>        for y in range(10):<br></div><div>            transposed_related_coords = [y, x for x, y in related_coords(x, y)]<br></div><div><br></div><div>    # This is not (given the "let's reintroduce leaking from comprehensions" proposal)<br></div><div>    for x in range(10):<br></div><div>        for y in range(10):<br></div><div>            related_interesting_coords = [x, y for x in related_x_coord(x, y) if is_interesting(y := f(x))]<br></div><div><br></div>Deliberately reintroducing stateful side effects into a nominally functional construct seems like a recipe for significant confusion, even if there are some cases where it might arguably be useful to folks that don't want to write a named function that returns multiple values instead.<br></div><div class="gmail_quote"><br><div>Cheers,<br></div><div>Nick.<br><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>