This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: No way to check whether Future is finished?
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.4
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: cool-RR, josh.r, sbt
Priority: normal Keywords:

Created on 2013-06-14 13:25 by cool-RR, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (6)
msg191126 - (view) Author: Ram Rachum (cool-RR) * Date: 2013-06-14 13:25
I have a `Future` and I want to check whether it's in finished state. It seems like I don't have a method to do that, right? (I could emulate the existing methods for checking Future state, but that would mean fiddling with private variables.)

Why not just expose the Future state in a property that automatically acquires `self._condition`? (Instead of a horde of methods.)
msg191143 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-06-14 18:44
Do you want something like

    f.done() and not f.cancelled() and f.exception() is None
msg191147 - (view) Author: Ram Rachum (cool-RR) * Date: 2013-06-14 19:10
I guess that'd be equivalent, yes.
msg222170 - (view) Author: Ram Rachum (cool-RR) * Date: 2014-07-03 12:38
What do you think about exposing this directly?
msg222246 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2014-07-04 00:29
Have an idea for a name? It already has a done method, which happens to cover the case of a Future having completed successfully, completed due to an exception or having been cancelled. Simply calling it "finished()", "completed()" etc. isn't markedly different from "done()".

Exposing it as a property would be a bad idea largely because it would be inconsistent with the rest of the Future interface that is purely method based (I suspect largely because some of the behaviors must be method based to allow arguments related to timeout and they just kept up the pattern).

The main argument I can see *against* making this easier than Richard's 2-3 part check (beyond the naming issue) is that it tends to encourage misuse of the library. Polling your Futures is a bad design 99% of the time (the same way loops over range(len(someseq)) are a bad idea most of the time; it's not that it doesn't work, it's that it's a backwards way to do it). In general:

1. If you need a single result now, you use future.result() directly
2. If you need to wait for a set of things to complete, you use:
  a. concurrent.futures.wait if you need all of them to finish before continuing
  b. concurrent.futures.as_completed if you can process them as they become available
3. If you don't have a loop processing worker results, but want the values to be used as they become available, you use future.add_done_callback() and let the result get processed asynchronously without your main thread becoming involved at all

Note: None of these cases really benefit from the existing status check methods. Instantaneous state checks are generally frowned upon in concurrent code, since program behavior can hinge on a microsecond race between the task and the checking thread, so polling is almost always worse than one of the more "event driven" approaches. I'm open to argument (I'm not omniscient), but I see this as making it even easier to do threading, rather than a legitimate improvement.
msg222247 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2014-07-04 00:32
Ugh. Left out a key word:

"I see this as making it even easier to do threading *badly*, rather than a legitimate improvement."
Date User Action Args
2022-04-11 14:57:46adminsetgithub: 62412
2020-11-23 19:48:56iritkatrielsetstatus: open -> closed
resolution: rejected
stage: resolved
2014-07-04 00:32:12josh.rsetmessages: + msg222247
2014-07-04 00:29:58josh.rsetnosy: + josh.r
messages: + msg222246
2014-07-03 12:38:03cool-RRsetmessages: + msg222170
2013-06-14 19:10:55cool-RRsetmessages: + msg191147
2013-06-14 18:44:18sbtsetnosy: + sbt
messages: + msg191143
2013-06-14 13:25:45cool-RRcreate