views:

453

answers:

3

There seems to be a lot of heated discussion on the net about the changes to the reduce() function in python 3.0 and how it should be removed. I am having a little difficulty understanding why this is the case; I find it quite reasonable to use it in a variety of cases. If the contempt was simply subjective, I cannot imagine that such a large number of people would care about it.

What am I missing? What is the problem with reduce()?

+2  A: 

People worry it encourages an obfuscated style of programming, doing something that can be achieved with clearer methods.

I'm not against reduce myself, I also find it a useful tool sometimes.

Eli Bendersky
+6  A: 

reduce() is not being removed -- it's simply being moved into the functools module. Guido's reasoning is that except for trivial cases like summation, code written using reduce() is usually clearer when written as an accumulation loop.

John Millikin
Gah, that's horrible reasoning :(
TraumaPony
Is it? Much of Python's philosophy is about writing code that is clear and obvious. A typical call to reduce() usually requires me to break out a pencil and graph what the function is being called with.
John Millikin
Unless you can show me a *significant* performance increase (2x at least), I'll take "clear and obvious" over "compactness of expression" any day.
Kevin Little
+22  A: 

As Guido says in his The fate of reduce() in Python 3000 post:

So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly.

There is an excellent example of a confusing reduce in the Functional Programming HOWTO article:

Quick, what's the following code doing?

total = reduce(lambda a, b: (0, a[1] + b[1]), items)[1]

You can figure it out, but it takes time to disentangle the expression to figure out what's going on. Using a short nested def statements makes things a little bit better:

def combine (a, b):
    return 0, a[1] + b[1]

total = reduce(combine, items)[1]

But it would be best of all if I had simply used a for loop:

total = 0
for a, b in items:
    total += b

Or the sum() built-in and a generator expression:

total = sum(b for a,b in items)

Many uses of reduce() are clearer when written as for loops.

DzinX
In that case it could be even easier: sum (b for a, b in items)
John Millikin
@John Millikin: Nice! :-)
DzinX
Ah, frightening -- now that I look in the link, the sum() line is directly your quote. Must have just missed it the first time.
John Millikin
@John Millikin: You're right! I missed it, too :) I added it now, thanks!
DzinX
The reduce code is not equivalent to the for loop. Here is the equivalent:`total = reduce(lambda total, (a,b): total + b, items, 0)`
Nathan Sanders
@Nathan Sanders: If you care only about the result, they are the same. If you care about underlying implementation, your reduce is still different from the for loop, as it uses one more variable (total).
DzinX