[Python-Dev] [PEP 3148] futures - execute computations asynchronously (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Fri Mar 5 16:53:27 CET 2010
- Previous message: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
- Next message: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
- Next message: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]