[Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Nick Coghlan]

Dj Gilcrease wrote:
> On Sun, Mar 7, 2010 at 6:50 AM, Jesse Noller <jnoller at gmail.com> wrote:
>> Making the tests and examples happy on windows is fine; but some
>> explanation is needed for the API changes.
>>
> 
> My primary motivation behind the API change is so there is just a
> single public Executor class that you tell what system to use instead
> of two separate classes. The use case I was thinking about is when a
> user is is unsure which system (threads or processes) they want to use
> so they just build the system with the defaults (which is threads)
> then it is a little easier to switch it to processes in the future
> instead of having to change imports and all instances of the class you
> just change the use keyword to switch between systems

Wouldn't a factory function serve that purpose just as well? Or even
just "from concurrent.futures import ProcessPoolExecutor as TaskExecutor".

That last form has the virtue that you can retrieve your executor from
anywhere rather than being limited to the two provided by the
concurrent.futures model.

I think the string based approach actually unduly constrains the API
despite superficially appearing to make it more flexible.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------