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/
