Repository navigation
Deprecate asyncio policy system #127949
Description
Activity
- added3.14bugs and security fixesbugs and security fixes
on Dec 14, 2024 - addedtype-featureA feature request or enhancementA feature request or enhancementand removed3.14bugs and security fixesbugs and security fixes
on Dec 14, 2024 asyncio.new_event_loop could just be deprecated in favour of asyncio.EventLoop
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-releaseI 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.Runnerandasyncio.runtoloop_factory=asyncio.EventLoopThis would allow policy users likepytest-asyncioto continue to useasyncio.get_event_loop()with the policy system, but would move most users off the systemFTR,
asyncio.get_event_loop1 in Python versions 3.10.0–3.10.8 and 3.11.0, an incorrect deprecation was added for this but it was backed out later because things likeasyncio.set_event_loop_policyweren't deprecated at that time.With the current plan all of this would be deprecated at the same time so there won't be any issue like that.
Footnotes
27 remaining items
SoundsSerious commented
on Apr 29, 2026 on Apr 29, 2026 · Hidden as resolvedshow commentMore actionsReopening for the removal of APIs in 3.16
Reacted by AnubhavB- addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directoryextension-modulesC modules in the Modules dirC modules in the Modules dir
on Jun 21, 2026 - added a commit that references this issue
on Jun 27, 2026
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDone
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
rather than currently
See these discussions for more background:
Functions and classes to be deprecated and later removed
asyncio.get_event_loop_policyasyncio.set_event_loop_policyasyncio.AbstractEventLoopPolicyasyncio.DefaultEventLoopPolicyasyncio.WindowsSelectorEventLoopPolicyasyncio.WindowsProactorEventLoopPolicyasyncio.set_event_loopFunctions to be modified
asyncio.get_event_loop- In 3.16 or later this will become an alias toget_running_loop.asyncio.new_event_loop- In 3.16 or later this will ignore custom policies and will be an alias toasyncio.EventLoopasyncio.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
set_event_loop->_set_event_loopandset_event_loopwill emit the warning then call_set_event_loopas 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 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)"]Linked PRs
asyncio.set_event_loop_policy#128024asyncio.get_event_loop_policy#128053asyncio.set_event_loop#128218test_tasks.py(GH-128172) #131805test_tasks.py(GH-128172) #131806Footnotes
https://docs.python.org/3.14/library/asyncio-policy.html ↩