[Python-Dev] [PEP 3148] futures - execute computations asynchronously
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:
> Ok, here is my take on it:
>> 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
> 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
for f in finished():
>> Return True if the call is currently being executed and cannot be
>> Return True if the call was successfully cancelled or finished
> 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
> 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, return_when=ALL_COMPLETED)
>> 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.
More information about the Python-Dev