On Nov 7, 2009, at 9:03 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
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.
______________________________
It's an easily rectified pity. Also, your not the only use case
addressed by multiprocessing, which is why stuff you wouldn't use is
in there.
Jesse
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
