[Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Nick Coghlan]

Jesse Noller wrote:
> The reason *why* is that I would like to also move the abstractions I
> have in multiprocessing *out* of that module, make them work with both
> threads and processes (if it makes sense) and reduce the
> multiprocessing module to the base primitive Process object. A
> concurrent package which implements common patterns built on top of
> the primitives we support is an objectively Good Thing.

Yes, I've often thought we should have a pool model that covers threads
as well as processes.

The reason I think "futures" works as a PEP and potential standard
library addition is that it is small enough to be readily reviewed and
maintained, and serves as a useful building block for more complex usage.

For a developer to get anything similar from a third party library is
almost certainly going to require buying into a much heavier framework.
A simple futures module provides a way to farm out worker tasks in a
standard fashion without having to build as much of your own
infrastructure every time.

I've read the various PEP checkins as they went by on the checkins list
- it gets a +0 from me (the only reason it isn't a +1 is because I
personally tend to write with a Thread+Queue style. However, I could
easily become a futures convert if they were readily available in the
standard library)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------