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

[Brian Quinlan]

On Feb 26, 2010, at 5:49 AM, Jesse Noller wrote:

> On Thu, Feb 25, 2010 at 12:27 PM, Jeffrey Yasskin  
> <jyasskin at gmail.com> wrote:
> ... snip
>>>
>>> In any case, I've updated the docs and PEP to indicate that  
>>> deadlocks are
>>> possible.
>>
>> Thanks. I still disagree, and think users are much more likely to be
>> surprised by occasional deadlocks due to cycles of executors than  
>> they are
>> about guaranteed deadlocks from cycles of futures, but I don't want  
>> to be
>> the only one holding up the PEP by insisting on this.
>> I think there are places the names could be improved, and Jesse  
>> probably has
>> an opinion on exactly where this should go in the package  
>> hierarchy, but I
>> think it will make a good addition to the standard library. Thanks  
>> for
>> working on it!
>> Jeffrey
>
> Yes; I think this needs to be part of a new "concurrent" package in
> the stdlib - e.g. concurrent.futures, understanding things within
> multiprocessing will be put in there shortly, and possibly other
> things such as a threadpool and other common sugary abstractions.


Are you imagining that futures would be subpackage of concurrent with  
a single logical namespace i.e.

concurrent/
   __init__.py
   futures/
     __init__.py
    threads.py
    processes.py
    ...

from concurrent.future import wait
from concurrent.future import ThreadPoolExecutor

Or should the futures package be merged into the concurrent package i.e.

concurrent/
   __init__.py
   futures.py
   threadpoolexecutor.py (was threads.py)
   processpoolexecutor.py (as processes.py)

from concurrent.future import wait
from concurrent.future.threadpoolexecutor import ThreadPoolExecutor

?


Cheers,
Brian