[Python-Dev] [PEP 3148] futures - execute computations asynchronously (original) (raw)

Brian Quinlan brian at sweetapp.com
Sat Mar 6 10:52:46 CET 2010

On 6 Mar 2010, at 09:54, Antoine Pitrou wrote:

Le Fri, 5 Mar 2010 17:03:02 +1100, Brian Quinlan <brian at sweetapp.com> a écrit :

The PEP lives here: http://python.org/dev/peps/pep-3148/ Ok, here is my take on it: cancel() Attempt to cancel the call. If the call is currently being executed then it cannot be cancelled and the method will return False, otherwise the call will be cancelled and the method will return True. I think it shouldn't return anything, and raise an exception if cancelling failed. It is really an error condition, and ignoring the result doesn't seem right.

In my experience with futures, canceling them is a best-effort
optimization that people use when another future fails. For example:

futures = [executor.submit(CopyDirectory, src, dest) for dest in ...] finished, unfinished = wait(futures, return_when=FIRST_EXCEPTION)

If there are unfinished futures then there must have been a failure

for f in unfinished:

No reason to waste bandwidth copying files if the operation has

already failed. f.cancel() for f in finished(): if f.exception(): raise f.exception()

Future.running()

Return True if the call is currently being executed and cannot be cancelled. Future.done() Return True if the call was successfully cancelled or finished running. These don't really make sense since the future is executing concurrently. By the time the result is returned, it can already be wrong. I advocate removing those two methods.

There methods are useful for logging - by displaying the count of
pending, running and completed futures you can estimate the progress
of the system.

The following Future methods are meant for use in unit tests and Executor implementations. Their names should then be preceded by an underscore ''. We don't want people to think they are public APIs and start relying on them.

Actually, as discussed on the stdlib-sig, these methods are designed
to make it possible for users to implement their own Executors so
we'll have keep the interface stable.

wait(fs, timeout=None, returnwhen=ALLCOMPLETED) [...]

This method should always be called using keyword arguments I don't think this is right. Keyword arguments are nice, but mandating them too often is IMO a nuisance (after all, it makes things longer to type and requires you to remember the exact parameter names). Especially when the method only takes at most 3 arguments. IMO, keyword-only arguments are mostly useful when there are a lot of positional arguments before, and you want to help the user use the right calling signature.

I agree, I'll change this.

Cheers, Brian

More information about the Python-Dev mailing list