From 77106b2c21e59d0466742cc3afa50f9e8345e186 Mon Sep 17 00:00:00 2001 From: Pablo Galindo Date: Sun, 10 Dec 2017 17:34:59 +0000 Subject: [PATCH] bpo-32114: Updated the documentation for get_event_loop to reflect the policy change (#4510) --- Doc/library/asyncio-eventloops.rst | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/Doc/library/asyncio-eventloops.rst b/Doc/library/asyncio-eventloops.rst index 7970e9039d..2097260e21 100644 --- a/Doc/library/asyncio-eventloops.rst +++ b/Doc/library/asyncio-eventloops.rst @@ -189,10 +189,15 @@ An event loop policy must implement the following interface: The default policy defines context as the current thread, and manages an event -loop per thread that interacts with :mod:`asyncio`. If the current thread -doesn't already have an event loop associated with it, the default policy's -:meth:`~AbstractEventLoopPolicy.get_event_loop` method creates one when -called from the main thread, but raises :exc:`RuntimeError` otherwise. +loop per thread that interacts with :mod:`asyncio`. An exception to this rule +happens when :meth:`~AbstractEventLoopPolicy.get_event_loop` is called from a +running future/coroutine, in which case it will return the current loop +running that future/coroutine. + +If the current thread doesn't already have an event loop associated with it, +the default policy's :meth:`~AbstractEventLoopPolicy.get_event_loop` method +creates one when called from the main thread, but raises :exc:`RuntimeError` +otherwise. Access to the global loop policy -- 2.50.1