bpo-31943: Add asyncio.Handle.cancelled() method

[decaz]

It would be handy to access the loop's time the Handle's callback will be called at if you are using delayed calls with "delay" (not "when") argument.
Also it is useful to know whether the call was cancelled through the special attribute.

https://bugs.python.org/issue31943

[mention-bot]

@decaz, thanks for your PR! By analyzing the history of the files in this pull request, we identified @1st1, @methane and @serhiy-storchaka to be potential reviewers.

[asvetlov]

@1st1 should we support it?
The change makes no harm but add version dependent behavior: user code should check if when attribute is present before accessing it.
On other side call_later() and family are low level API methods, most likely user should not call them from async functions.

[1st1]

I'm OK with .cancelled, but I've no idea why we need .when. @decaz do you have a real use-case for it?

[1st1]

BTW, .cancelled should be a method, not property, similar to Future.cancelled() method.

[decaz]

@1st1 yes, .when can be used to determine how much time is left before the delayed call is executed. For instance:

seconds_left = handler.when - loop.time()

Now it's impossible as the time the handler will be called at is calculated internally.

[1st1]

I specifically asked you about a real use case for ‘.when’. That means you should have told us about a real problem you encountered implementing a protocol or a server using asyncio, which was unsolvable without the ‘.when’ attribute.

We won’t add something just because there are hypothetical use cases for it.

[decaz]

@1st1 agree with you, just wanted to add such an attribute on the case if it will be convenient. I have rebased the branch.

[asvetlov]

Please add .. versionadded:: 3.6

[1st1]

3.7 :)

[decaz]

OK, added. I hope it will be backported to 3.6?)

[1st1]

No. Asyncio is no longer provisional and this is not a bug fix.

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[asvetlov]

BTW Handler and TimeHandler are heavy used by asyncio core.
Maybe adding C implementation makes sense?
Even maybe supporting free lists for these classes might affect asyncio performance?

[1st1]

Maybe adding C implementation makes sense?

I can see it improving the performance somewhat. But please hold off with the implementation before PEP 550 (or its successor) lands.

[decaz]

I have made the requested changes; please review again.

[bedevere-bot]

Thanks for making the requested changes!

@asvetlov: please review the changes made to this pull request.

[asvetlov]

Thanks for contribution!