Hm, but doesn't the OP's example require *synchronously* reading and writing the state?
On Sun, Feb 16, 2020 at 4:47 PM Kyle Stanley <aeros...@gmail.com> wrote: > > 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()`. > > > On Sun, Feb 16, 2020 at 6:00 PM Antoine Pitrou <solip...@pitrou.net> > wrote: > >> On Sun, 16 Feb 2020 17:41:36 -0500 >> Kyle Stanley <aeros...@gmail.com> wrote: >> > >> > As a side note, are we still interested in expanding the public API for >> the >> > Future class? Particularly for a public means of accessing the state. >> The >> > primary motivation for it was this topic, but I could easily the same >> > issues coming up with custom Future and Executor classes; not to mention >> > the general debugging usefulness for being able to log the current >> state of >> > the future (without relying on private members). >> >> 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). >> >> 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/7ZQE3IB4NR7ZPLLKWIY54PW3X5K6YWUF/ >> 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/BT5AKV4AOACU6TFYI6MIQXC6RK7BQFEK/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/7LPVJ6OPAFG7IZDGYU5FDXD4SX54KDN4/ Code of Conduct: http://python.org/psf/codeofconduct/