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

Antoine Pitrou solipsis at pitrou.net
Fri Nov 13 15:22:18 CET 2009


Hey,

> Future remains unchanged - I disagree that Deferreds would be better,  
> that .exception() is not useful, and that .result() should be  
> renamed .get() or .__call__().

On what grounds do you disagree with the latter?

Another question: is the caught exception an attribute of the future? If
so, is there any mechanism to clean it up (and its traceback) once the
future has been "consumed"?

> map becomes a utility function:
> 
> def map(executor, *iterables, timeout=None)

Why? map() can be defined on the ABC, so that subclasses don't have to
provide their own implementation.

An utility function which looks like a method and shadows the name of a
built-in looks like a bad choice to me.

> wait becomes a utility function that can wait on any iterable of  
> Futures:
> 
> def wait(futures, return_when=ALL_COMPLETED)

Does it work if the futures are executed by different executors?
If not, it should be an Executor method.

> return_when indicates when the method should return. It must be one of  
> the following constants:
> 
>      NEXT_COMPLETED
>      NEXT_EXCEPTION
>      ALL_COMPLETED

Can you outline the difference between NEXT_COMPLETED and
NEXT_EXCEPTION? What happens if I ask for NEXT_COMPLETED but the next
future to complete raises an exception? etc.

> def itercompleted(futures, timeout=None):
> 
> Returns an iterator that returns a completed Future from the given  
> list when __next__() is called. If no Futures are completed then  
> __next__() is called then __next__() waits until one does complete.

What about futures which complete with an exception?

> with futures.ThreadPoolExecutor(50) as executor:
>    fs = [executor.submit(load_url, url, timeout=30) for url in URLS]

The use of "with" here still is counter-intuitive, because it does not
clean up resources immediately as it would seem to do. "with" is always
synchronous in other situations.

> What do you think? Are we moving in the right direction?

Perhaps, yes, but there are still lots of dark areas.

Besides, it's obvious that the package has to mature, and should be
tested by other people.




More information about the stdlib-sig mailing list