[stdlib-sig] futures - a new package for asynchronous execution

Jeffrey Yasskin jyasskin at gmail.com
Fri Feb 26 05:03:19 CET 2010

On Thu, Feb 25, 2010 at 7:54 PM, Jesse Noller <jnoller at gmail.com> wrote:
> I'm on the fence. I took a few minutes to think about this today, and
> my gut says concurrent with a single logical namespace - so:
> from concurrent import futures
> futures.ThreadPoolExecutor
> And so on. Others might balk at a deeper namespace, but then say we add:
> concurrent/
>    futures/
>    pool.py (allows for a process pool, or threadpool)
>    managers.py
> And so on. I'm trying to mentally organize things to "be like"
> java.util.concurrent [1] - ideally we could move/consolidate the
> common sugar into this package, and remove the other "stuff" from
> multiprocessing as well. That way multiprocessing can become "just"
> Process and the locking stuff, ala threading, and the rest of the
> other nice-things can be made to work with threads *and* processes ala
> what you've done with futures.

My gut agrees, FWIW.

More information about the stdlib-sig mailing list