On Sat, Nov 7, 2009 at 9:48 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > 2009/11/7 Jesse Noller <jnol...@gmail.com>: >>> 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. >> >> 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. > > I'm not quite sure what you mean there. Are you suggesting that there > could be a threading.Pool which mirrors multiprocessing.Pool? If so, > then yes I agree - but of course, it wouldn't be available till > 2.7/3.2. > > What I suppose I was thinking of as a "pity" was that it wasn't > already added to threading. I thought multiprocessing was "just" the > threading API using multiple processes - but it looks like it's more > than that. >
See my response to frank: There's nothing blocking this except for: 1> A patch 2> Tests 3> Docs It's been on my wish list for ~2 years now, I might get it done in the next decade. Also, multiprocessing has never been "just" the threading API on top of processes. Part of the PEP for it's inclusion was that it had other items in it of value. jesse _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
