> 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 at cosc.canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4