> 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.
Yeah, I don't feel quite as strongly about future.set_state(). My primary motivation was to work on a complete means of extending the Future class through a public API, starting with the future's state. But it might be too (potentially) detrimental for the average user to be worth the more niche case of being able to extend Future without needing to use the private members. Upon further consideration, I think it would be better to stick with future.state() for now, since it has more of a general-purpose use case. If it's specifically documented in similar manner to queue.qsize(); stating something along the lines of "Return the approximate state of the future. Note that this state is only advisory, and is not guaranteed." > No strong opinion on this, but it sounds ok. That means > `future.state()` would return an enum value, not a bare string? Yeah, presumably with each using auto() for the value. For simplified review purposes though, I'll likely do these in separate PRs, but attached to the same bpo issue: https://bugs.python.org/issue39645. I'll also update the issue to reduce the scope a bit (mainly removing future.set_state()). On Mon, Feb 17, 2020 at 5:08 AM Antoine Pitrou <solip...@pitrou.net> wrote: > 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/ >
_______________________________________________ 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/WI6NWWOT4BCXNZNNGX53KM64LSC2PPKJ/ Code of Conduct: http://python.org/psf/codeofconduct/
