Chris Angelico writes:
It's not too hard to create your own dataflow class if you want one. It can start with any arbitrary iterable, and then have your map and filter methods just the same.
One thing I noticed when implementing this class (yours is better, so I'm not posting mine :-) is that you and I both implemented .map in the obvious way for this use case, but the map function takes multiple iterables. On the other hand, filter takes only one iterable argument. Obviously, you can implement multifilter def multifilter(func, *iterables): filter(lambda x: func(*x), zip(*iterables)) I think generalizing to this is a YAGNI, since it's so simple. Also, returning an iterable of tuples may not be the right thing. That is, you might want it to return a tuple of iterables, but that would be messy to implement, and in general can't be done space-efficiently I think. This apparently is a "no one ever needed it." Changing map to take a sequence of iterables is a non-starter, since that would be backward incompatible. There's also implementing zip's strict argument, eg, def zippymap(func, *iterables, strict=False): return map(lambda x: func(*x), zip(*iterables, strict)) and corresponding zippymappers for any other mappers (including filter). This seems like it might be useful extension to the functions in the stdlib for the same reason that it's useful for zip itself. Even though it's so easy to implement in terms of zip, it would be more discoverable as a documented argument to the functions. Comments? Steve