Alex Martelli <aleaxit at yahoo.com> writes: > Unfortunately, with the sum change regressed, d.asum times to > 8.4e+03 usec per loop, so it clearly cannot be considered any > more:-). So, there might be space for an accumulator function > patterned on map but [a] which stops on the shortest sequence > like zip and [b] does NOT build a list of results, meant to be called > a bit like map is in the 'amap' example above. itertools is a great > little collection of producers and manipulators of iterators, but the > "accumulator functions" might provide the "one obvious way" to > _consume_ iterators for common cases; and accumulating by > calling an accumulator-object's mutator method, such as > tot.extend above, on all items of an iterator, clearly is pretty common. I *think* I see what you're getting at here, but I'm struggling to follow in the absence of concrete use cases. As we're talking about library functions, I'd suggest that your suggested "accumulator functions" start their life as an external module - maybe even in Python, although I take our point about the speed advantages of C. With a bit of "real life" use, migration into the standard library might be more of an obvious step. Paul. -- This signature intentionally left blank
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