Mar 22, 2023 · Mar 18, 2023 · Mar 18, 2023 · Mar 18, 2023 · Mar 18, 2023 · Mar 20, 2023
diff --git a/Doc/library/asyncio-task.rst b/Doc/library/asyncio-task.rst
 :class:`asyncio.TaskGroup` and :func:`asyncio.timeout`,
 are implemented using cancellation internally and might misbehave if
 a coroutine swallows :exc:`asyncio.CancelledError`. Similarly, user code
 should not call :meth:`uncancel <asyncio.Task.uncancel>`.
 should not generally call :meth:`uncancel <asyncio.Task.uncancel>`.
 However, in such cases when supprssing :exc:`asynci.CancelledError` is
 truly desired, it is necessary to also call :meth:`uncancel` to completely
 remove the cancellation state.

 .. _taskgroups:

      Therefore, unlike :meth:`Future.cancel`, :meth:`Task.cancel` does
      not guarantee that the Task will be cancelled, although
      suppressing cancellation completely is not common and is actively
      discouraged.
      discouraged.  Should the coroutine nevertheless decide to suppress
      the cancellation, it needs to call :meth:`Task.uncancel` in addition
      to catching the exception.

      .. versionchanged:: 3.9
         Added the *msg* parameter.
      with :meth:`uncancel`.  :class:`TaskGroup` context managers use
      :func:`uncancel` in a similar fashion.

      If end-user code is, for some reason, suppresing cancellation by
      catching :exc:`CancelledError`, it needs to call this method to remove
      the cancellation state.

   .. method:: cancelling()

      Return the number of pending cancellation requests to this Task, i.e.,
Original file line number	Diff line number	Diff line change
Expand Up		@@ -306,7 +306,10 @@ The asyncio components that enable structured concurrency, like
		:class:`asyncio.TaskGroup` and :func:`asyncio.timeout`,
gvanrossum marked this conversation as resolved. Show resolvedHide resolved
		are implemented using cancellation internally and might misbehave if
		a coroutine swallows :exc:`asyncio.CancelledError`. Similarly, user code
		should not call :meth:`uncancel <asyncio.Task.uncancel>`.
		should not generally call :meth:`uncancel <asyncio.Task.uncancel>`.
		However, in such cases when supprssing :exc:`asynci.CancelledError` is
kristjanvalur marked this conversation as resolved. OutdatedShow resolvedHide resolved
		truly desired, it is necessary to also call :meth:`uncancel` to completely
kristjanvalur marked this conversation as resolved. OutdatedShow resolvedHide resolved
		remove the cancellation state.

		.. _taskgroups:

Expand DownExpand Up		@@ -1148,7 +1151,9 @@ Task Object
		Therefore, unlike :meth:`Future.cancel`, :meth:`Task.cancel` does
		not guarantee that the Task will be cancelled, although
		suppressing cancellation completely is not common and is actively
		discouraged.
		discouraged. Should the coroutine nevertheless decide to suppress
		the cancellation, it needs to call :meth:`Task.uncancel` in addition
		to catching the exception.

		.. versionchanged:: 3.9
		Added the msg parameter.
Expand DownExpand Up		@@ -1238,6 +1243,10 @@ Task Object
		with :meth:`uncancel`. :class:`TaskGroup` context managers use
		:func:`uncancel` in a similar fashion.

		If end-user code is, for some reason, suppresing cancellation by
		catching :exc:`CancelledError`, it needs to call this method to remove
		the cancellation state.

		.. method:: cancelling()

		Return the number of pending cancellation requests to this Task, i.e.,
Expand Down