@@ -300,13 +300,17 @@ in the task at the next opportunity.
300
300
It is recommended that coroutines use ``try/finally `` blocks to robustly
301
301
perform clean-up logic. In case :exc: `asyncio.CancelledError `
302
302
is 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.
304
305
305
306
The asyncio components that enable structured concurrency, like
306
307
:class: `asyncio.TaskGroup ` and :func: `asyncio.timeout `,
307
308
are implemented using cancellation internally and might misbehave if
308
309
a 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.
310
314
311
315
.. _taskgroups :
312
316
@@ -620,32 +624,26 @@ Timeouts
620
624
The context manager produced by :func: `asyncio.timeout ` can be
621
625
rescheduled to a different deadline and inspected.
622
626
623
- .. class :: Timeout()
627
+ .. class :: Timeout(when )
624
628
625
629
An :ref: `asynchronous context manager <async-context-managers >`
626
- that limits time spent inside of it .
630
+ for cancelling overdue coroutines .
627
631
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.
629
638
630
639
.. method :: when() -> float | None
631
640
632
641
Return the current deadline, or ``None `` if the current
633
642
deadline is not set.
634
643
635
- The deadline is a float, consistent with the time returned by
636
- :meth: `loop.time `.
637
-
638
644
.. method :: reschedule(when: float | None)
639
645
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.
649
647
650
648
.. method :: expired() -> bool
651
649
@@ -962,6 +960,13 @@ Introspection
962
960
.. versionadded :: 3.7
963
961
964
962
963
+ .. function :: iscoroutine(obj)
964
+
965
+ Return ``True `` if *obj * is a coroutine object.
966
+
967
+ .. versionadded :: 3.4
968
+
969
+
965
970
Task Object
966
971
===========
967
972
@@ -1148,7 +1153,9 @@ Task Object
1148
1153
Therefore, unlike :meth: `Future.cancel `, :meth: `Task.cancel ` does
1149
1154
not guarantee that the Task will be cancelled, although
1150
1155
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.
1152
1159
1153
1160
.. versionchanged :: 3.9
1154
1161
Added the *msg * parameter.
@@ -1238,6 +1245,10 @@ Task Object
1238
1245
with :meth: `uncancel `. :class: `TaskGroup ` context managers use
1239
1246
:func: `uncancel ` in a similar fashion.
1240
1247
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
+
1241
1252
.. method :: cancelling()
1242
1253
1243
1254
Return the number of pending cancellation requests to this Task, i.e.,
0 commit comments