Being able to use a pool to easily run 'map' over an iterable is very powerful, but it would also be nice to run 'filter' (or potentially 'ifilter' or 'filter_async', in keeping with the patterns already present).

Why is it insufficient to run a synchronous 'filter' over the list returned by 'Pool.map'? These functional constructs are inherently composable, and we should favor composing simple implementations of each rather than implementing special cases of them throughout the stdlib.

I think there's a clear reason for 'map' to be parallelizable because the function you're applying over the iterable could be quite expensive. 'filter' would only benefit from this if the comparison you're running is expensive, which seems like an unlikely and ill-advised use case. You can also rewrite your expensive 'filter' as a 'map' if you really need to.

The points made by Travis are clear and solid.

Closing as this functionality is already handled well and no exceptional situations are being argued for that would require a special case.

The main point the OP didn't make is exactly the issue that Pool.map returns a list which is potentially very large given that multiprocessing is used to process large amounts of data.

So IMHO either there should be the possibility to exclude elements from being saved in memory (i.e. Pool.filter) or Pool.map shouldn't return a list but just an iterable.