<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 May 2018 at 06:10, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Greg Ewing <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>>'<wbr>]<br>
<span class="">> This whole discussion started because someone wanted a way<br>
> to bind a temporary result for use *within* a comprehension.<br>
<br>
</span>It's been noted several times recently that the example PEP 572 gives<br>
as _not_ working:<br>
<br>
    total = 0<br>
    progressive_sums = [total := total + value for value in data]<br>
<br>
was the original use case that prompted work on the PEP.  You gotta<br>
admit that's ironic ;-)<br></blockquote><br></div><div class="gmail_quote">After pondering this case further, I think it's also worth noting that that *particular* example could also be addressed by:<br><br></div><div class="gmail_quote">1. Allowing augmented assignment *expressions*<br></div><div class="gmail_quote">2. Changing the scoping rules for augmented assignment operations in general such that they *don't change the scope of the referenced name*<br><br></div><div class="gmail_quote">Writing "i += n" without first declaring the scope of "i" with "i = 0", "nonlocal i" or "global i" is one of the most common sources of UnboundLocalError after all, so I'd be surprised to find anyone that considered the current augmented assignment scoping rules to be outside the realm of reconsideration.<br><br></div><div class="gmail_quote">The accumulation example would then be written:<br><br>    total = 0<br>
    progressive_sums = [total += value for value in data]<br></div><div class="gmail_quote">    if progressive_sums:<br></div><div class="gmail_quote">        assert total == progressive_sums[-1]<br></div><div class="gmail_quote">
<br></div>The question would then turn to "What if you just want to bind the target name, without considering the old value?". And then *that's* where "NAME : = EXPR" would come in: as an augmented assignment operator that used augmented assignment scoping semantics, rather than regular local name binding semantics.<br><br></div><div class="gmail_extra">That would mean *directly* overturning PEP 3099's rejection of the idea of using "NAME := EXPR" to imply "nonlocal NAME" at function scope, but that's effectively on the table for implicit functions anyway (and I'd prefer to have ":=" be consistent everywhere, rather than having to special case the implicit scopes).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <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>