[Python-Dev] [PEP 3148] futures - execute computations asynchronously
solipsis at pitrou.net
Fri Mar 5 23:54:04 CET 2010
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.
> 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.
> 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.
More information about the Python-Dev