> That sounds useful to me indeed. I assume you mean something like a
> state() method? We already have Queue.qsize() which works a bit like
> this (unlocked and advisory).
Yep, a `Future.state()` method is exactly what I had in mind! I hadn't considered that `Queue.qsize()` was analogous, but that's a perfect example.
Based on the proposal in the OP, I had considered that it might also be needed to be able to manually set the state of the future through something like a `Future.set_state()`, which would have a parameter for accessing it safely through the condition's RLock, and another without it (in case they want to specify their own, such as in the OP's example code).
Lastly, it seemed also useful to be able to publicly use the future state constants. This isn't necessary for extending them, but IMO it would look better from an API design perspective to use `future.set_state(cf.RUNNING)` instead of `future.set_state(cf._base.RUNNING)` or `future.set_state("running") [1].
Combining the above, this would look something like `future.set_state(cf.FINISHED)`, instead of the current private means of modifying them with `future._state = cf._base.FINISHED` or `future._state = "finished"`.
Personally, I'm most strongly in favor of adding Future.state(), as it would be personally useful for me (for reasons previously mentioned); but I think that the other two would be useful for properly extending the Future class without having to access private members. This was more formally proposed in
https://bugs.python.org/issue39645.
[1] - Setting running was just an example, although normally that would be just done in the executor through `Future.set_running_or_notify_cancel()`.