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

[Jeffrey Yasskin]

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