@@ -300,13 +300,17 @@ in the task at the next opportunity.
300300It is recommended that coroutines use ``try/finally `` blocks to robustly
301301perform clean-up logic. In case :exc: `asyncio.CancelledError `
302302is explicitly caught, it should generally be propagated when
303- clean-up is complete. Most code can safely ignore :exc: `asyncio.CancelledError `.
303+ clean-up is complete. :exc: `asyncio.CancelledError ` directly subclasses
304+ :exc: `BaseException ` so most code will not need to be aware of it.
304305
305306The asyncio components that enable structured concurrency, like
306307:class: `asyncio.TaskGroup ` and :func: `asyncio.timeout `,
307308are implemented using cancellation internally and might misbehave if
308309a coroutine swallows :exc: `asyncio.CancelledError `. Similarly, user code
309- should not call :meth: `uncancel <asyncio.Task.uncancel> `.
310+ should not generally call :meth: `uncancel <asyncio.Task.uncancel> `.
311+ However, in cases when suppressing :exc: `asyncio.CancelledError ` is
312+ truly desired, it is necessary to also call ``uncancel() `` to completely
313+ remove the cancellation state.
310314
311315.. _taskgroups :
312316
@@ -620,32 +624,26 @@ Timeouts
620624 The context manager produced by :func: `asyncio.timeout ` can be
621625 rescheduled to a different deadline and inspected.
622626
623- .. class :: Timeout()
627+ .. class :: Timeout(when )
624628
625629 An :ref: `asynchronous context manager <async-context-managers >`
626- that limits time spent inside of it .
630+ for cancelling overdue coroutines .
627631
628- .. versionadded :: 3.11
632+ ``when `` should be an absolute time at which the context should time out,
633+ as measured by the event loop's clock:
634+
635+ - If ``when `` is ``None ``, the timeout will never trigger.
636+ - If ``when < loop.time() ``, the timeout will trigger on the next
637+ iteration of the event loop.
629638
630639 .. method :: when() -> float | None
631640
632641 Return the current deadline, or ``None `` if the current
633642 deadline is not set.
634643
635- The deadline is a float, consistent with the time returned by
636- :meth: `loop.time `.
637-
638644 .. method :: reschedule(when: float | None)
639645
640- Change the time the timeout will trigger.
641-
642- If *when * is ``None ``, any current deadline will be removed, and the
643- context manager will wait indefinitely.
644-
645- If *when * is a float, it is set as the new deadline.
646-
647- if *when * is in the past, the timeout will trigger on the next
648- iteration of the event loop.
646+ Reschedule the timeout.
649647
650648 .. method :: expired() -> bool
651649
@@ -962,6 +960,13 @@ Introspection
962960 .. versionadded :: 3.7
963961
964962
963+ .. function :: iscoroutine(obj)
964+
965+ Return ``True `` if *obj * is a coroutine object.
966+
967+ .. versionadded :: 3.4
968+
969+
965970Task Object
966971===========
967972
@@ -1148,7 +1153,9 @@ Task Object
11481153 Therefore, unlike :meth: `Future.cancel `, :meth: `Task.cancel ` does
11491154 not guarantee that the Task will be cancelled, although
11501155 suppressing cancellation completely is not common and is actively
1151- discouraged.
1156+ discouraged. Should the coroutine nevertheless decide to suppress
1157+ the cancellation, it needs to call :meth: `Task.uncancel ` in addition
1158+ to catching the exception.
11521159
11531160 .. versionchanged :: 3.9
11541161 Added the *msg * parameter.
@@ -1238,6 +1245,10 @@ Task Object
12381245 with :meth: `uncancel `. :class: `TaskGroup ` context managers use
12391246 :func: `uncancel ` in a similar fashion.
12401247
1248+ If end-user code is, for some reason, suppresing cancellation by
1249+ catching :exc: `CancelledError `, it needs to call this method to remove
1250+ the cancellation state.
1251+
12411252 .. method :: cancelling()
12421253
12431254 Return the number of pending cancellation requests to this Task, i.e.,
0 commit comments