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

[Antoine Pitrou]

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.

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

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

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

Regards

Antoine.