2009/11/7 Brian Quinlan <br...@sweetapp.com>: > > On 7 Nov 2009, at 22:06, Paul Moore wrote: >> I'm not convinced it should go in multiprocessing, though. After all, >> it uses threading rather than multiple processes. > > > Actually, you can choose weather to use threads or processes. The current > implementation includes a ThreadPoolExecutor and a ProcessPoolExecutor > (which is an argument to making it a separate package) and should be > abstract enough to accommodate other strategies in the future.
That's my point. Multiprocessing is about just that - multiprocessing. I wouldn't use it (or even think of looking in it) if I wanted to write a single-process multithreaded program (which is what I usually do on Windows). I was responding to the suggestion that your futures module would work as a component of the multiprocessing package. Actually, it's a pity that things like the Pool class only exist in multiprocessing. A threaded version of that would be very useful to me as well. Paul. _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
