In article <002401c39907$0176f5a0$e841fea9 at oemcomputer>, "Raymond Hettinger" <raymond.hettinger at verizon.net> wrote: > In the course of writing up Pep 289, it became clear that > the future has a number of accumulator functions in store. > Each of these is useful with iterators of all stripes and > each helps eliminate a reason for using reduce(). Maybe it would be useful to get some feeling for how much other functions get used in reduce? I took a look through some of my own code, and found: - three loops with |= and &= that could have been done as a reduction on a generator expression (but for now will stay loops) - one call reduce(f,...) where f is not known until run time - no products. My guess is that, after sum, the functions used in reduce get a lot more diverse, and that trying to replace all of them with builtins is not feasible. -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science
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