On Fri, Aug 9, 2019 at 9:03 AM Peter O'Connor wrote:

Alright hear me out here:

I've often found that it would be useful for the following type of expression to be condensed to a one-liner:

def running_average(x_seq): averages = [] avg = 0 for t, x in enumerate(x_seq): avg = avg*t/(t+1) + x/(t+1) averages.append(avg) return averages

Because really, there's only one line doing the heavy lifting here, the rest is kind of boilerplate.

But it's boilerplate that communicates the starting state of your loop which is useful to know and to have be very clearly communicated.

Then I learned about the beautiful and terrible "for x in [value]":

def running_average(x_seq): return [avg for avg in [0] for t, x in enumerate(x_seq) for avg in [avg*t/(t+1) + x/(t+1)]]

Many people find this objectionable because it looks like there are 3 for loops, but really there's only one: loops 0 and 2 are actually assignments.

**My Proposal**

What if we just officially bless this "using for as a temporary assignment" arrangement, and allow "for x=value" to mean "assign within the scope of this for". It would be identical to "for x in [value]", just more readable. The running average function would then be:

def running_average(x_seq): return [avg for avg=0 for t, x in enumerate(x_seq) for avg = avg * t/(t+1) + x / (t+1)]

I personally don't find that more readable then the unrolled version you're trying to avoid. And based on the amount of grief we got for the walrus operator I wouldn't expect much uptake on this as being considered more readable by others either. (And remember that "Readability counts"). -Brett

------ P.S. 1 I am aware of Python 3.8's new "walrus" operator, which would make it:

def running_average(x_seq): avg = 0 return [avg := avg*t/(t+1) + x / (t+1) for t, x in enumerate(x_seq)]

But it seems ugly and bug-prone to be initializing a in-comprehension variable OUTSIDE the comprehension.

------ P.S. 2 The "for x = value" syntax can achieve things that are not nicely achievable using the := walrus. Consider the following example (wherein we carry forward a "hidden" variable h but do not return it):

y_seq = [y for h=0 for x in x_seq for y, h = update(x, h)]

There's not really a nice way to do this with the walrus because you can't (as far as I understand) combine it with tuple-unpacking. You'd have to do something awkward like:

yh = None, 0 y_seq, _ = zip(*(yh := update(x, yh[1]) for x in x_seq)) ------

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RHW5AU... Code of Conduct: http://python.org/psf/codeofconduct/

Peter O'Connor wrote:

Alright hear me out here: I've often found that it would be useful for the following type of expression to be condensed to a one-liner: def running_average(x_seq): averages = [] avg = 0 for t, x in enumerate(x_seq): avg = avg*t/(t+1) + x/(t+1) averages.append(avg) return averages Because really, there's only one line doing the heavy lifting here, the rest is kind of boilerplate. Then I learned about the beautiful and terrible "for x in [value]": def running_average(x_seq): return [avg for avg in [0] for t, x in enumerate(x_seq) for avg in [avg*t/(t+1) + x/(t+1)]] Many people find this objectionable because it looks like there are 3 for loops, but really there's only one: loops 0 and 2 are actually assignments.

You can solve this via `itertools.accumulate` in a concise and clear way: [x/n for n, x in enumerate(it.accumulate(x_seq), 1)]

My Proposal What if we just officially bless this "using for as a temporary assignment" arrangement, and allow "for x=value" to mean "assign within the scope of this for". It would be identical to "for x in [value]", just more readable. The running average function would then be: def running_average(x_seq): return [avg for avg=0 for t, x in enumerate(x_seq) for avg = avg * t/(t+1) + x / (t+1)] ------ P.S. 1 I am aware of Python 3.8's new "walrus" operator, which would make it: def running_average(x_seq): avg = 0 return [avg := avg*t/(t+1) + x / (t+1) for t, x in enumerate(x_seq)] But it seems ugly and bug-prone to be initializing a in-comprehension variable OUTSIDE the comprehension. ------ P.S. 2 The "for x = value" syntax can achieve things that are not nicely achievable using the := walrus. Consider the following example (wherein we carry forward a "hidden" variable h but do not return it): y_seq = [y for h=0 for x in x_seq for y, h = update(x, h)] There's not really a nice way to do this with the walrus because you can't (as far as I understand) combine it with tuple-unpacking. You'd have to do something awkward like: yh = None, 0 y_seq, _ = zip(*(yh := update(x, yh[1]) for x in x_seq))

You can't use `:=` with tuple unpacking but you can use it with tuples directly; this requires a definition of the initial tuple (preferably outside the loop) but this is i.m.o. a plus since it clearly marks the initial conditions for your algorithm: yh = (None, 2) # initial values [(yh := update(x, yh[1]))[0] for x in x_seq] If you really ever have the need to carry a variable over into a comprehension (which might be a valid thing, for example in a class body) then you can still resort to an additional `for` loop (as you've already indicated); after all it's not too bad and you can even put the different loops on different lines + add a comment if necessary: class Foo: a = 1 # this won't work: b = [x*a for x in range(5)] # we can carry `a` over to the comprehension as follows: b = [x*a for a in [a] for x in range(5)] Using just `for = ...` is not much of a difference, especially since most people will see the `for` and immediately assume it's a loop (so in that sense it's even more confusing).