On Thu, Feb 25, 2010 at 7:54 PM, Jesse Noller <jnol...@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. _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
