Maybe Guido's right, and functional programming doesn't belong in Python. Of course, that would imply that functional programmers don't belong in Python, either... I hear Perl's more receptive these days, and you won't find Ruby or Smalltalk giving up blocks/lambdas anytime soon. Or heck, try a real functional language like Haskell, Ocaml, Dylan, Nice, Scheme, or what have you. Even C++ is getting more functional these days. Too bad to see Python going backwards.
Bitterness abounds! What I was completely unable to find, though, was any example of Python programmers saying, “I use
reduce() all the time. I really hope it doesn't go away.” In fact a Google search for python "i use reduce" found only 13 hits.
Following one of them, I found this, which I think is fair:
My Solar System calculator BOTEC has a similar application; when plotting courses, you can have an arbitrary number of transfers, and those transfers can each have an arbitrary number of burns. So it's quite convenient to do a reduce on the list of burns (a sequence of sequences), and then a reduce on the list of deltavees for the transfers (a sequence of numerics).
Note the difference in tone. Strangely, moving
reduce() out of
builtins and into a
functional module, where it unquestionably belongs, is not the end of the world.
Another way of looking at all this is that Python doesn't need
reduce because it has syntax for all three. For
filter, you can use list comprehensions. For
reduce, there's an even cleverer syntax. It does everything
reduce can do, but it's more readable; it runs faster; it's much easier to change; it can accumulate multiple values without having to pack and unpack tuples—it even has an early-escape feature. It's called a