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

Jeffrey Yasskin jyasskin at gmail.com
Sat Mar 6 03:00:56 CET 2010

On Fri, Mar 5, 2010 at 2:54 PM, Antoine Pitrou <solipsis at pitrou.net> 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.

The caller can't avoid the error here by querying the future, because of the problem you point out below, so I'm inclined to think that "the future was already started" should be a return value rather than an exception (although that may be my C++ background showing through). Would calling the method try_cancel() work better?

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.

"done()" can only be wrong in one direction though. If it returns True, it'll never again return False, which can be useful (although perhaps only for polling, which might be an argument for removing it anyway).

"running()" becomes True and then False again, so I agree with your objection. A "started()" function would only go from False to True once. Maybe that's a better function?

Jeffrey

More information about the Python-Dev mailing list