Thinking about the way this works in APL, where you can say things like
total = + / numbers
one reason it's so compact is that the system knows what the identity is for each operator, so you don't have to specify the starting value explicitly. Another is the use of a binary operator.
So if we postulate a "reducing protocol" that requires function objects to have a __div__ method that performs reduction with a suitable identity, then we can write
total = operator.add / numbers
Does that look succinct enough?
It still suffers from my main problem with reduce(), which is not its verbosity (far from it) but that except for some special cases (mainly sum and product) I have to stand on my head to understand what it does. This is even the case for examples like reduce(lambda x, y: x + y.foo, seq) which is hardly the epitomy of complexity. Who here knows for sure it shouldn't rather be reduce(lambda x, y: x.foo + y, seq) without going through an elaborate step-by-step execution? This is inherent in the definition of reduce, and no / notation makes it go away for me. --Guido van Rossum (home page: http://www.python.org/~guido/)