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

Antoine Pitrou 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: 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, 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.

Regards

Antoine.

More information about the Python-Dev mailing list