Skip to content

gh-96377: Update asyncio policy doc intro paras to be clear and accurate #97603

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Sep 27, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Doc/library/asyncio-dev.rst
Original file line number Diff line number Diff line change
Expand Up @@ -109,7 +109,7 @@ that the event loop runs in.

There is currently no way to schedule coroutines or callbacks directly
from a different process (such as one started with
:mod:`multiprocessing`). The :ref:`Event Loop Methods <asyncio-event-loop>`
:mod:`multiprocessing`). The :ref:`asyncio-event-loop-methods`
section lists APIs that can read from pipes and watch file descriptors
without blocking the event loop. In addition, asyncio's
:ref:`Subprocess <asyncio-subprocess>` APIs provide a way to start a
Expand Down
7 changes: 5 additions & 2 deletions Doc/library/asyncio-eventloop.rst
Original file line number Diff line number Diff line change
@@ -1,6 +1,8 @@
.. currentmodule:: asyncio


.. _asyncio-event-loop:

==========
Event Loop
==========
Expand Down Expand Up @@ -92,7 +94,7 @@ This documentation page contains the following sections:
loop APIs.


.. _asyncio-event-loop:
.. _asyncio-event-loop-methods:

Event Loop Methods
==================
Expand Down Expand Up @@ -1598,6 +1600,7 @@ Do not instantiate the class directly.


.. _asyncio-event-loops:
.. _asyncio-event-loop-implementations:

Event Loop Implementations
==========================
Expand Down Expand Up @@ -1644,7 +1647,7 @@ on Unix and :class:`ProactorEventLoop` on Windows.

Abstract base class for asyncio-compliant event loops.

The :ref:`Event Loop Methods <asyncio-event-loop>` section lists all
The :ref:`asyncio-event-loop-methods` section lists all
methods that an alternative implementation of ``AbstractEventLoop``
should have defined.

Expand Down
2 changes: 1 addition & 1 deletion Doc/library/asyncio-llapi-index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ Event Loop Methods
==================

See also the main documentation section about the
:ref:`event loop methods <asyncio-event-loop>`.
:ref:`asyncio-event-loop-methods`.

.. rubric:: Lifecycle
.. list-table::
Expand Down
36 changes: 25 additions & 11 deletions Doc/library/asyncio-policy.rst
Original file line number Diff line number Diff line change
Expand Up @@ -7,22 +7,29 @@
Policies
========

An event loop policy is a global per-process object that controls
the management of the event loop. Each event loop has a default
policy, which can be changed and customized using the policy API.

A policy defines the notion of *context* and manages a
separate event loop per context. The default policy
defines *context* to be the current thread.

By using a custom event loop policy, the behavior of
:func:`get_event_loop`, :func:`set_event_loop`, and
:func:`new_event_loop` functions can be customized.
An event loop policy is a global (per-interpreter) object
Copy link
Contributor

Choose a reason for hiding this comment

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

An event loop policy is a global (per-interpreter)

I know the details here are hard to understand but "per-interpreter" can give false sense that asyncio can work under multiple interpreters. It doesn't since it caches the thread id and does not checks the interp id. It would be better to remove per-interpreter altogether here.

See #91375

Copy link
Member

Choose a reason for hiding this comment

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

Oh, you're right, I remember now. We should add a note to that issue to add "per-interpreter" back here once that's been fixed. (It's not rocket science to fix it, IIRC, just work?)

Copy link
Member

Choose a reason for hiding this comment

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

Oh and since this is already merged we'd need a new PR. :-(

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay done #97618

used to get and set the current :ref:`event loop <asyncio-event-loop>`,
as well as create new event loops.
The default policy can be :ref:`replaced <asyncio-policy-get-set>` with
:ref:`built-in alternatives <asyncio-policy-builtin>`
to use different event loop implementations,
or substituted by a :ref:`custom policy <asyncio-custom-policies>`
that can override these behaviors.

The :ref:`policy object <asyncio-policy-objects>`
gets and sets a separate event loop per *context*.
Copy link
Member

Choose a reason for hiding this comment

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

Should/could context link to anything?
It's only mentioned here and in a couple of methods below, but it's otherwise not defined in this page.

Copy link
Member Author

Choose a reason for hiding this comment

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

I had the same question and asked Guido that in #96377 and it seems there isn't really anything more to link it to; see his reply for more details.

Copy link
Member

Choose a reason for hiding this comment

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

Perhaps we should add -- in a separate PR -- a concise list of asyncio-related terms/concepts (coroutines, tasks, futures, event loops, transports, contexts, policies, ...).

Copy link
Member Author

Choose a reason for hiding this comment

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

If we did so as a proper Sphinx glossary, they could be easily referenced with, e.g. :term:`coroutine` from anywhere (including via intersphinx).

Copy link
Member

Choose a reason for hiding this comment

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

Good luck defining context. It has at least four unrelated uses/meanings:

  • context manager, e.g. TaskGroup and timeout; see also contextlib
  • a collection of context variables (see contextvars) used to pass contextual state along to child tasks (e.g. create_task(..., context=...))
  • a dict with assorted things passed to exception handlers
  • The context referred to by the docs for event loop policies

This is per-thread by default,
though custom policies could define *context* differently.

Custom event loop policies can control the behavior of
:func:`get_event_loop`, :func:`set_event_loop`, and :func:`new_event_loop`.

Policy objects should implement the APIs defined
in the :class:`AbstractEventLoopPolicy` abstract base class.


.. _asyncio-policy-get-set:

Getting and Setting the Policy
==============================

Expand All @@ -40,6 +47,8 @@ for the current process:
If *policy* is set to ``None``, the default policy is restored.


.. _asyncio-policy-objects:

Policy Objects
==============

Expand Down Expand Up @@ -86,6 +95,8 @@ The abstract event loop policy base class is defined as follows:
This function is Unix specific.


.. _asyncio-policy-builtin:

asyncio ships with the following built-in policies:


Expand Down Expand Up @@ -117,6 +128,7 @@ asyncio ships with the following built-in policies:

.. availability:: Windows.


.. _asyncio-watchers:

Process Watchers
Expand Down Expand Up @@ -270,6 +282,8 @@ implementation used by the asyncio event loop:
.. versionadded:: 3.9


.. _asyncio-custom-policies:

Custom Policies
===============

Expand Down