Skip to content
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

Deprecate asyncio policy system #127949

Open
kumaraditya303 opened this issue Dec 14, 2024 · 3 comments
Open

Deprecate asyncio policy system #127949

kumaraditya303 opened this issue Dec 14, 2024 · 3 comments
Assignees
Labels
topic-asyncio type-feature A feature request or enhancement

Comments

@kumaraditya303
Copy link
Contributor

asyncio's policy system deprecation

asyncio's policy system1 has been a source of confusion and problems in asyncio for a very long time. The policies no longer serve a real purpose. Loops are always per thread, there is no need to have a "current loop" when no loop is currently running. This issue discusses the changes to deprecate it in Python 3.14 and schedule its removal in 3.16 or later.

The usual user applications would use the runner APIs (see flowchart) while those who want more control like Jupyter project can create an event loop and manage it themselves, the difference would be that instead of them first getting the policy then event loop then can directly create it like

loop = MyCustomEventLoop()
loop.run_until_complete(task)

rather than currently

asyncio.set_event_loop_policy(MyPolicy())
policy = asyncio.get_event_loop_policy()
loop = policy.new_event_loop()
loop.run_until_complete(task)

See these discussions for more background:

Functions and classes to be deprecated and later removed
  • asyncio.get_event_loop_policy
  • asyncio.set_event_loop_policy
  • asyncio.AbstractEventLoopPolicy
  • asyncio.DefaultEventLoopPolicy
  • asyncio.WindowsSelectorEventLoopPolicy
  • asyncio.WindowsProactorEventLoopPolicy
  • asyncio.set_event_loop
Functions to be modified
  • asyncio.get_event_loop - This will emit warning when creating event loop from policy, later this will become an alias of get_running_loop.
  • asyncio.new_event_loop - This will emit warning when a custom event loop is used, later this will ignore custom policies.
  • asyncio.run & asyncio.Runner - In 3.16 or later this will be modified to not use policy system as that will be gone and rely solely on loop_factory.

The Grand Plan

  • To minimize changes, all the deprecated functions will be underscored i.e. set_event_loop -> _set_event_loop and set_event_loop will emit the warning then call _set_event_loop as its underlying implementation. This way internally asyncio can still call these functions until they are removed without need of many ignore warnings and the tests too can easily be adapted.
  • The deprecated classes will emit warnings when they are subclassed as it was done for child watchers.
  • The runner APIs will be remain unmodified but making sure that correct warnings are emitted internally when policy system is used.

The Future

---
title: Flowchart for asyncio.run
---
flowchart TD
    A["asyncio.run(coro, loop_factory=...)"] --> B{loop_factory}
    B -->|loop_factory is None| D{platform}
    B -->|loop_factory is not None| E["loop = loop_factory()"]
    D --> |Unix| F["loop = SelectorEventLoop()"]
    D --> |Windows| G["loop = ProactorEventLoop()"]
    E --> H
    F --> H
    G --> H 
    H["loop.run_until_complete(coro)"]
Loading

Footnotes

  1. https://docs.python.org/3.14/library/asyncio-policy.html

@kumaraditya303 kumaraditya303 added topic-asyncio 3.14 new features, bugs and security fixes labels Dec 14, 2024
@github-project-automation github-project-automation bot moved this to Todo in asyncio Dec 14, 2024
@picnixz picnixz added type-feature A feature request or enhancement and removed 3.14 new features, bugs and security fixes labels Dec 14, 2024
@graingert graingert self-assigned this Dec 14, 2024
@graingert
Copy link
Contributor

asyncio.new_event_loop could just be deprecated in favour of asyncio.EventLoop

@asvetlov
Copy link
Contributor

I support the deprecation in general, details are the subject for future discussion.
For example, policies are used by very many libraries. It's better for, e.g., maintainers of pytest-asyncio if we keep the deprecation for 5 Python releases (the issue proposes 2 years).
Let me sleep on other proposed details.
But anyway, I agree we should deprecate policies at least in a very soft form. If we agree on the 5 year deprecation period we can increase the pressure release-to-release

@graingert
Copy link
Contributor

graingert commented Dec 15, 2024

I support the deprecation in general, details are the subject for future discussion. For example, policies are used by very many libraries. It's better for, e.g., maintainers of pytest-asyncio if we keep the deprecation for 5 Python releases (the issue proposes 2 years). Let me sleep on other proposed details. But anyway, I agree we should deprecate policies at least in a very soft form. If we agree on the 5 year deprecation period we can increase the pressure release-to-release

how about in 2 years (2 Python releases so 3.16 or 3.27) we swap the default loop_factory for asyncio.Runner and asyncio.run to loop_factory=asyncio.EventLoop This would allow policy users like pytest-asyncio to continue to use asyncio.get_event_loop() with the policy system, but would move most users off the system

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-asyncio type-feature A feature request or enhancement
Projects
Status: Todo
Development

No branches or pull requests

4 participants