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)
It occurs to me that, with generator expressions, such cases could be rewritten as reduce(lambda x, y: x + y, (z.foo for z in seq)) i.e. any part of the computation that only depends on the right argument can be factored out into the generator. So I might have to take back some of what I said earlier about generator comprehensions being independent of reduce. But if I understand you correctly, what you're saying is that the interesting cases are the ones where there isn't a ready-made binary function that does what you want, in which case you're going to have to spell everything out explicitly anyway one way or another. In that case, the most you could gain from a reduce syntax would be that it's an expression rather than a sequence of statements. But the same could be said of list comprehensions -- and *was* said quite loudly by many people in the early days, if I recall correctly. What's the point, people asked, when writing out a set of nested loops is just about as easy? Somehow we came to the conclusion that being able to write a list comprehension as an expression was a valuable thing to have, even if it wasn't significantly shorter or clearer. What about reductions? Do we feel differently? If so, why? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+