On Fri, Mar 5, 2010 at 2:54 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > Le Fri, 5 Mar 2010 17:03:02 +1100, > Brian Quinlan <br...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
