Replace reduce with listcomprehension?

[ssecorp]

GvR wants to eliminate all the functional stuff (lambda map reduce
filter) which kind of makes sense for Python, listcomprehensions are
more efficient(at least as implemented inpython) from what i have
gathered and they can express everything map/reduce/filter with
crippled lambdas can.

but what about this:
reduce(lambda x,y:x*y+x,[1,2,3,4,5,6])

how would I express that in a listcomprehension?

 

[Luis M. González]

Actually, GvR announced that "lambda, filter and map will stay (the
latter two with small changes, returning iterators instead of lists).
Only reduce will be removed from the 3.0 standard library. You can
import it from functools."

Check the full article here: http://www.artima.com/weblogs/viewpost.jsp?thread=98196

Luis

 

[Diez B. Roggisch]

GvR wants to eliminate all the functional stuff (lambda map reduce
filter) which kind of makes sense for Python, listcomprehensions are
more efficient(at least as implemented inpython) from what i have
gathered and they can express everything map/reduce/filter with
crippled lambdas can.

but what about this:
reduce(lambda x,y:x*y+x,[1,2,3,4,5,6])

how would I express that in a listcomprehension?

You can't. And AFAIK your are wrong - GvR doesn't wan to eliminate the
functional stuff.

http://www.artima.com/weblogs/viewpost.jsp?thread=98196
http://www.python.org/dev/peps/pep-3099/



Diez

 

[Luis M. González]

Correction:
I guess the link I provided above is old news...
In the more recent Python 3000 FAQ, GvR says:

Q. If you're killing reduce(), why are you keeping map() and filter()?

A. I'm not killing reduce() because I hate functional programming; I'm
killing it because almost all code using reduce() is less readable
than the same thing written out using a for loop and an accumulator
variable. On the other hand, map() and filter() are often useful and
when used with a pre-existing function (e.g. a built-in) they are
clearer than a list comprehension or generator expression. (Don't use
these with a lambda though; then a list comprehension is clearer and
faster.)

So it seems only reduce will be eliminated.

Luis

 

[Diez B. Roggisch]

Correction:
I guess the link I provided above is old news...
In the more recent Python 3000 FAQ, GvR says:

Q. If you're killing reduce(), why are you keeping map() and filter()?

A. I'm not killing reduce() because I hate functional programming; I'm
killing it because almost all code using reduce() is less readable
than the same thing written out using a for loop and an accumulator
variable. On the other hand, map() and filter() are often useful and
when used with a pre-existing function (e.g. a built-in) they are
clearer than a list comprehension or generator expression. (Don't use
these with a lambda though; then a list comprehension is clearer and
faster.)

So it seems only reduce will be eliminated.

Nope. From the link you provided yourself:

"""
Only reduce will be removed from the 3.0 standard library. You can
import it from functools.
"""

Diez

 

[bearophileHUGS]

Luis M. González, citing Guido:

A. I'm not killing reduce() because I hate functional programming; I'm
killing it because almost all code using reduce() is less readable
than the same thing written out using a for loop and an accumulator
variable.

(So reduce is now in itertools). Try to pry folds from the hands of
haskell programmers
I think they think that folds are more clear than explicit loops...

Bye,
bearophile

 

[Steven D'Aprano]

Nope. From the link you provided yourself:

"""
Only reduce will be removed from the 3.0 standard library. You can
import it from functools.
"""

functools isn't in the standard library???

*wink*

Seriously, I think Guido meant "built-ins". Since I don't agree with him
that reduce() is hard to read, I disagree that accumulators are easier to
use. But since reduce is only an import away, I'm satisfied.