This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author travis.thieman
Recipients Mike.Drob, sbt, travis.thieman
Date 2014-11-15.20:28:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1416083316.87.0.909665938728.issue22864@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2014-11-15 20:28:36travis.thiemansetrecipients: + travis.thieman, sbt, Mike.Drob
2014-11-15 20:28:36travis.thiemansetmessageid: <1416083316.87.0.909665938728.issue22864@psf.upfronthosting.co.za>
2014-11-15 20:28:36travis.thiemanlinkissue22864 messages
2014-11-15 20:28:36travis.thiemancreate