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.)

Do you want something like

    f.done() and not f.cancelled() and f.exception() is None

I guess that'd be equivalent, yes.

What do you think about exposing this directly?

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.

Ugh. Left out a key word:

"I see this as making it even easier to do threading *badly*, rather than a legitimate improvement."