[stdlib-sig] futures - a new package for asynchronous execution

[Paul Moore]

2009/11/7 Jesse Noller <jnoller at 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 <fwierzbicki at gmail.com>:
> On Sat, Nov 7, 2009 at 12:29 AM, Brian Quinlan <brian at 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.