"Guido van Rossum" <guido@python.org> wrote in message news:200310230248.h9N2meb01254@12-236-54-216.client.attbi.com...
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?
I do and Raymond Hettinger should. Doc bug 821701 addressed this confusion. I suggested the addition of "The first (left) argument is the accumulator; the second (right) is the update value from the sequence. The accumulator starts as the initializer, if given, or as seq[0]. " but don't know yet what Raymond actually did. For remembering, the arg order corresponds to left associativity: ...(((a op b) op c) op d) ... . For clarity, the updater should be written with real arg names: lambda sum, item: sum + item.foo Now sum.foo + item is pretty obviously wrong. I think it a mistake to make the two args of the update function look symmetric when they are not. Even if the same type, the first represents a cumulation of several values (and the last return value) while the second is just one (new) value. Terry J. Reedy