[Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

Michel Desmoulin desmoulinmichel at gmail.com
Mon Oct 24 09:34:27 EDT 2016


+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?
>
>
>


More information about the Python-ideas mailing list