Skip to content

Conversation

@mohsinm-dev
Copy link
Contributor

@mohsinm-dev mohsinm-dev commented Nov 8, 2025

Fixes issue #141186 by documenting that cancelling a Task cancels what it's waiting for.

Problem

The docs said cancelling a coroutine waiting on a Future cancels the Future, but didn't mention this also happens with Tasks. Users didn't know Tasks work the same way.

Solution

  • Added "or Task" to the documentation where it only mentioned Future
  • Explained that cancellation goes down the whole chain of waiting tasks
  • Mentioned that Tasks inherit from Future so they work the same

Testing

Ran the exact code from the issue - it works as expected. Tested multiple scenarios to confirm the behavior.

Documentation-only change. No code was modified.


📚 Documentation preview 📚: https://cpython-previews--141249.org.readthedocs.build/

discouraged. Should the coroutine nevertheless decide to suppress
the cancellation, it needs to call :meth:`Task.uncancel` in addition
to catching the exception.

Copy link
Member

@StanFromIreland StanFromIreland Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have trailing whitespace here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just removed it.

@mohsinm-dev mohsinm-dev force-pushed the fix-gh-141186-asyncio-only branch from 743e34a to f4bb1e8 Compare November 8, 2025 14:45
will cause the Task to throw a :exc:`CancelledError` exception into
the wrapped coroutine. If a coroutine is awaiting on a Future
object during cancellation, the Future object will be cancelled.
or Task object during cancellation, the awaited object will be cancelled.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It actually supports any future-like objects, you can say it like "if coroutine is awaiting on future-like object then that will be cancelled", with sphinx markers as necessary

the cancellation, it needs to call :meth:`Task.uncancel` in addition
to catching the exception.

If the Task being cancelled is currently awaiting another Task or
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

@mohsinm-dev mohsinm-dev force-pushed the fix-gh-141186-asyncio-only branch from f4bb1e8 to 2811031 Compare November 8, 2025 15:24
:class:`asyncio.Task` inherits from :class:`Future` all of its
APIs except :meth:`Future.set_result` and
:meth:`Future.set_exception`.
:meth:`Future.set_exception`. This includes the cancellation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is redundant, the exceptions are already noted rest are same by default

the cancellation, it needs to call :meth:`Task.uncancel` in addition
to catching the exception.

If the Task being cancelled is currently awaiting a future-like
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If the Task being cancelled is currently awaiting a future-like
If the Task being cancelled is currently awaiting on a future-like

Clarifies that cancelling a Task awaiting another Task or Future will
also cancel the awaited object. This behavior was undocumented despite
being fundamental to asyncio's cancellation architecture.

Changes:
- Updated general Task description to mention Task cancellation propagation
- Added explicit explanation in Task.cancel() method documentation
- Clarified that Tasks inherit Future's cancellation behavior

Addresses issue python#141186 where users were unaware this cancellation
propagation was intentional architectural behavior, not a side effect.

The fix uses the exact wording suggested by the issue reporter and
documents the _fut_waiter implementation behavior that enables the
propagation down entire await chains.
@kumaraditya303 kumaraditya303 merged commit b36f01d into python:main Nov 9, 2025
32 checks passed
@github-project-automation github-project-automation bot moved this from Todo to Done in Docs PRs Nov 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Documentation in the Doc dir skip news

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants