On Tue, Nov 23, 2021 at 7:47 PM Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
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.
Extending map to more than just one function and one iterable is done in different ways by different languages. I don't think it necessarily needs to be implemented the same way in a pipeline as it is in a stand-alone map function; the pipeline is, by its nature, working with a single iterable, so if its map method took anything more than a single argument, it could just as easily be interpreted as "pass these arguments to the function" (so you could >>iter(x).map(int, 16)<< to convert hex to decimal) rather than as extra iterables. Which is why I kept it simple and didn't allow more args :)
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.
Agreed, not really a lot of point.
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."
I think you're right there.
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?
Given that I don't actually want a pipeline like this, I'm not the best one to ask, but I would strongly favour ultra-simple APIs. ChrisA