<div dir="ltr"><div>Well, whether you factor out the loop-function is a separate issue.  Lets say we do:</div><div><br></div><div>    smooth_signal = [average = compute_avg(average, x) for x in signal from average=0]</div><div><br></div><div>Is just as readable and maintainable as your expanded version, but saves 4 lines of code.  What's not to love?</div><div><br></div><div><br></div><div><br></div><div><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 5:55 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5 April 2018 at 22:26, Peter O'Connor <<a href="mailto:peter.ed.oconnor@gmail.com">peter.ed.oconnor@gmail.com</a>> wrote:<br>
> I find this a bit awkward, and maintain that it would be nice to have this<br>
> as a built-in language construct to do this natively.  You have to admit:<br>
><br>
>     smooth_signal = [average = (1-decay)*average + decay*x for x in signal<br>
> from average=0.]<br>
><br>
> Is a lot cleaner and more intuitive than:<br>
><br>
>     dev compute_avg(avg, x):<br>
>         return (1 - decay)*avg + decay * x<br>
><br>
>     smooth_signal =<br>
> itertools.islice(itertools.<wbr>accumulate(itertools.chain([<wbr>initial_average],<br>
> signal), compute_avg), 1, None)<br>
<br>
</span>Not really, I don't... In fact, factoring out compute_avg() is the<br>
first step I'd take in converting the proposed syntax into something<br>
I'd find readable and maintainable. (It's worth remembering that when<br>
you understand the subject of the code very well, it's a lot easier to<br>
follow complex constructs, than when you're less familiar with it -<br>
and the person who's unfamiliar with it could easily be you in a few<br>
months).<br>
<br>
The string of itertools functions are *not* readable, but I'd fix that<br>
by expanding them into an explicit loop:<br>
<br>
    smooth_signal = []<br>
    average = 0<br>
    for x in signal:<br>
        average = compute_avg(average, x)<br>
        smooth_signal.append(average)<br>
<br>
If I have that wrong, it's because I misread *both* the itertools<br>
calls *and* the proposed syntax. But I doubt anyone would claim that<br>
it's possible to misunderstand the explicit loop.<br>
<span class=""><br>
> Moreover, if added with the "last" builtin proposed in the link, it could<br>
> also kill the need for reduce, as you could instead use:<br>
><br>
>     last_smooth_signal = last(average = (1-decay)*average + decay*x for x in<br>
> signal from average=0.)<br>
<br>
</span>    last_smooth_signal = 0<br>
    for x in signal:<br>
        last_smooth_signal = compute_avg(last_smooth_<wbr>signal, x)<br>
<br>
or functools.reduce(compute_avg, signal, 0), if you prefer reduce() -<br>
I'm not sure I do.<br>
<br>
Sorry, this example has pretty much confirmed for me that an explicit<br>
loop is *far* more readable.<br>
<span class="HOEnZb"><font color="#888888"><br>
Paul.<br>
</font></span></blockquote></div><br></div>