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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
