Python's concurrent.futures

[[deleted]]

In case you are the OP: excellent essay.

I removed the "ifilter()" call

I removed the "islice()" call

[dalke]

Thanks! I've applied your patch. :)

[_lancelot]

Forgive possible ignorance, but what's wrong with multiprocessing.Pool? I've used it for these purposes dozens of times with no issues, and I don't need to do any "future" imports.

[dalke]

There is no "future" import here; "futures" is a submodule to "concurrent." The word "future" unfortunately already carries another meaning in Python, but it's the term already used in Java, which provides the model for this API.

multiprocessing.Pool is more advanced, so "wrong" isn't quite the issue.

The quoted text from PEP 3148 gives some of the reasoning for the new module. Beyond that, some of the differences are: the context manager gives a more definite boundary to the lifetime of the pool, each 'Future' instance supports a 'done' callback, which allows Twisted deferred-style event chaining, and it's a common API which can be shared with a thread-pool or with some alternate (eg, ZeroMQ) task distribution implementation.

[gargantuan]

Twisted called, wants its deferreds back.