+1, especially given that reduce is not something you use very often. You loop and you filter everyday, but you definitely don't need the cumulative result of a sequence everyday. Python already have good any, all, sum and string concatenation stories so most of the FP usual suspect are taken care of. And remember that even when we do have something missing that we use often, it's not always enough to convince Guido to change the language for it. E.G, we have an old and recurrent debate about adding a keyword to assign a temporary calculation in comprehension list so that: [x[0].upper() for x in stuff() if x[0].upper()] can become: [x[0].upper() as word for x in stuff() if word] (and many other variants) All went to a dead end. So if you want to add the accumulate feature to the syntax, you better have a VERY GOOD reason. Le 23/10/2016 à 17:59, Steven D'Aprano a écrit :
On Sun, Oct 23, 2016 at 12:57:10PM -0200, Danilo J. S. Bellini wrote:
The idea is to let generator expressions and list/set comprehensions have a clean syntax to access its last output. That would allow them to be an alternative syntax to the scan higher-order function [1] (today implemented in the itertools.accumulate function), which leads to an alternative way to write a fold/reduce. It would be nice to have something like:
[cut suggested syntax]
instead of a reduce:
[cut four existing ways to solve the problem]
Why do we need a FIFTH way to solve this problem? What you are describing is *exactly* the use case for a reduce or fold function. Why add special magic syntax to make comprehensions do even more?
Not everything needs to be a one liner. It's okay to import reduce to do a reduce. Its okay to write an actual for-loop.
Actually, I already wrote a solution for something similar to that: PyScanPrev [2].
Ah, that makes SIX existing solutions. Do we need a seventh?