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

[Jesse Noller]

On Sat, Nov 7, 2009 at 9:49 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
>> 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...
>
> Well, feel free to propose a patch for threading.py.
> I'm not sure this has anything to do with the discussion about futures
> anyway.
>
> Regards
>
> Antoine.
>

It may smell off topic Antoine - but it fundamentally isn't.
Multiprocessing exposes a lot more "goodies" than the threading
module. Threading lacks parity (and actually can't have it for some
things) with multiprocessing.

The futures package actually adds a nice API for a given set of tasks
on top of both threading and multiprocessing, and so begs the question
"how do alternative implementations which don't have multiprocessing"
deal with a new package which offers access to an API of which part
builds on multiprocessing.

I don't think that question is going to be solved in the context of
this particular discussion, given that any solution to that question
lacks something Brian's futures package has - working code.

On the other hand, possibly pushing futures into a concurrent.*
namespace within the standard library means that you could have
concurrent.futures, concurrent.map, concurrent.apply and so on, and
pull the things which multiprocessing does and threading can as well
into that concurrent package.

jesse