On Sun, 16 Feb 2020 19:46:13 -0500
Kyle Stanley <aeros...@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.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/APZRZPV5YPBQ7TOERXFODISMUII2MOUL/
Code of Conduct: http://python.org/psf/codeofconduct/
