On Sun, 16 Feb 2020 19:46:13 -0500 Kyle Stanley <aeros167@gmail.com> wrote:
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).
I'm much more lukewarm on set_state(). How hard is it to reimplement one's own Future if someone wants a different implementation? By allowing people to change the future's internal state, we're also giving them a (small) gun to shoot themselves with.
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].
No strong opinion on this, but it sounds ok. That means `future.state()` would return an enum value, not a bare string? Regards Antoine.