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

[Brian Quinlan]

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, 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.

Cheers,
Brian