[Python-Dev] [PEP 3148] futures - execute computations asynchronously (original) (raw)

Jesse Noller jnoller at gmail.com
Fri Mar 5 15:50:28 CET 2010

On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman <ironfroggy at gmail.com> wrote:

A young library solving an old problem in a way that conflicts with many of the other implementations available for years and with zero apparent users in the wild is not an appropriate candidate for a PEP.

Baloney. A young library providing some syntactic sugar which uses primitives in the standard library to implement a common pattern is fine for a PEP. We've hashed this out pretty heavily on the stdlib-sig list prior to bringing it here. By the same argument, we should shunt all of the recent unittest changes and improvements into space, since golly, other people did it, why should we.

This is something relatively simple, which I would gladly add in an instant to the multiprocessing package - but Brian's one-upped me in that regard and is providing something which works with both threads and processes handily. Take a look at multiprocessing.Pool for example

Let me also state - "my" vision of where futures would live would be in a concurrent package - for example:

from concurrent import futures

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.

For example, how many of us have sat down and implemented a thread pool on top of threading, I would hazard to say that most of us who use threading have done this, and probably more than once. It stands to reason that this is a common enough pattern to include in the standard library.

In any case; consider me a strong +1 to adding it.

jesse

More information about the Python-Dev mailing list