How do asyncio.get_running_loop() and asyncio.get_event_loop() differ, and which should library code call?

**Two lookups that used to look interchangeable and never were.** Asyncio keeps at most one *running* loop per thread, and separately a *current* loop per thread — the one `asyncio.set_event_loop()` installed, which may or may not be running. The two lookup functions differ in which of those they will settle for. `asyncio.get_running_loop()` (3.7+) returns the running loop and nothing else. No running loop, no result: it raises `RuntimeError: no running event loop`. That strictness is the feature. Called from inside a coroutine, a callback, or anything the loop itself is driving, it is guaranteed to hand back the loop that is actually driving you, and it can never invent one. `asyncio.get_event_loop()` tries the running loop first and falls back to the thread's current loop. Historically, when there was neither, it would *create* one and install it — which is where the trouble lived. That fallback is gone: 3.12 emitted a `DeprecationWarning` when it had to create a loop, and 3.14 turns the no-loop case into an error. ```pycon >>> import asyncio >>> asyncio.get_event_loop() RuntimeError: There is no current event loop in thread 'MainThread'. ``` **Why the old fallback caused real bugs.** Consider an image-thumbnail worker whose queue module opened with a module-level `LOOP = asyncio.get_event_loop()` and scheduled its retry callbacks on `LOOP`. On old versions that line ran at import time and quietly manufactured loop *A*. Later, `asyncio.run(main())` created loop *B* and ran everything on it. Callbacks scheduled on *A* never fired, because nothing ever turned *A*'s crank — and the failure was invisible: no exception, no warning, just work that silently never happened. The bug was also order-dependent in the worst way. Breaking a circular import at startup by moving an import into a function changed *when* the module was first imported, which changed which loop the global captured, which flipped the symptom on and off between deployments. Making the no-loop case raise converts that class of bug into an immediate, obvious startup crash. **Inside a running loop the two agree.** Both return the same object, so the argument is never about the value; it is about what happens outside async context. `get_running_loop()` fails loudly there, which is what you want in a library that has no business creating loops for its caller. ```python import asyncio async def show(): print(asyncio.get_running_loop() is asyncio.get_event_loop()) # True asyncio.run(show()) ``` **What replaced the old habits.** Storing a loop in a global was often done so objects could be told which loop to use. That need is gone: the `loop` parameter was removed from asyncio's synchronization primitives and queues in 3.10, and they now bind to the running loop when they first need it. So the modern shape is that nothing holds a loop reference across the program; code that truly needs the loop object — to schedule a plain callback, or to hand work to an executor — calls `asyncio.get_running_loop()` at the moment it needs it, inside async context. **Threads that are not running a loop.** A worker thread that wants its own asyncio work does not fetch a loop from the main thread; it runs `asyncio.run()` itself, or explicitly builds one with `asyncio.new_event_loop()` and installs it for that thread with `asyncio.set_event_loop()`. Loops are per-thread and never shared: passing one thread's loop to another thread and calling its methods there is a race, since almost every loop method must be called from the loop's own thread. **The summary an interviewer wants:** `get_running_loop()` inside async code, `asyncio.run()` (or `asyncio.Runner`) at the process entry point, `set_event_loop()` only when you are deliberately setting up a loop for a thread, and `get_event_loop()` essentially never in new code — it survives mostly for compatibility with pre-3.7 patterns, and on 3.14 its remaining sharp edge is a `RuntimeError` rather than a silent wrong answer.