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. 2009/11/7 Frank Wierzbicki <fwierzbi...@gmail.com>: > On Sat, Nov 7, 2009 at 12:29 AM, Brian Quinlan <br...@sweetapp.com> wrote: > >> Right now multiprocessing is ahead of threading in terms of features. >> Pool.map() in particular is a pretty powerful idiom that has no equivalent >> in threading. > This is the area where I am most worried. Though multiprocessing is a > drop in replacement for threading, threading is not currently a drop > in replacement for multiprocessing. If multiprocessing doesn't make > sense for Jython and we need to tell our users that they should just > use threading, threading needs to do everything that multiprocessing > does... or maybe there needs to be a higher level package? Yes, *that's* my point. Paul. _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
