What is the problem with reduce()?

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()?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

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.

Method 2

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.

Method 3

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.

Method 4

The primary reason of reduce’s existence is to avoid writing explicit for loops with accumulators. Even though python has some facilities to support the functional style, it is not encouraged. If you like the ‘real’ and not ‘pythonic’ functional style – use a modern Lisp (Clojure?) or Haskell instead.

Method 5

Using reduce to compute the value of a polynomial with Horner’s method is both compact and expressive.

Compute polynomial value at x.
a is an array of coefficients for the polynomial

def poynomialValue(a,x):
   return reduce(lambda value, coef: value*x + coef, a)

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0