Message231216
| 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:36 | travis.thieman | set | recipients:
+ travis.thieman, sbt, Mike.Drob |
| 2014年11月15日 20:28:36 | travis.thieman | set | messageid: <1416083316.87.0.909665938728.issue22864@psf.upfronthosting.co.za> |
| 2014年11月15日 20:28:36 | travis.thieman | link | issue22864 messages |
| 2014年11月15日 20:28:36 | travis.thieman | create |
|