This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Ilya.Kulakov
Recipients Ilya.Kulakov, gvanrossum, r.david.murray, vstinner, yselivanov
Date 2016-05-06.19:58:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1462564692.26.0.224104952002.issue26969@psf.upfronthosting.co.za>
In-reply-to
Content
> Why does it have to be a standard part of asyncio?

I've only seen few libraries that deal with asyncio so far (aiohttp, pyzmq), but my general impression is that this is a generic problem.

With asyncio code should be (ideally) written as a set of coroutines which schedule each other or are called in response to monitored events. That means (and asyncio very implementation shows that) loop has to be "self" for all coroutines it executes.

Thread-local default event loop is a good solution to get an entry point into the event loop from an out-of-event-loop execution location. But (ideally) there will be exactly one place in code where this behavior is convenient: when you "instantiate" and run event loop. After that the event loop becomes "self" for each coroutine it may run and therefore it's now convenient for get_event_loop to return currently running event loop.

Probably it would make sense to modify behavior of the default policy to make get_event_loop to return Thread-local event loop when called from out-of-event-loop and return currently running event loop when called from within a coroutine.

> Why don't you just use 'loop = asyncio.get_event_loop()' in places where you need the loop?

As David pointed out, I'm not using thread-local event loop.
History
Date User Action Args
2016-05-06 19:58:12Ilya.Kulakovsetrecipients: + Ilya.Kulakov, gvanrossum, vstinner, r.david.murray, yselivanov
2016-05-06 19:58:12Ilya.Kulakovsetmessageid: <1462564692.26.0.224104952002.issue26969@psf.upfronthosting.co.za>
2016-05-06 19:58:12Ilya.Kulakovlinkissue26969 messages
2016-05-06 19:58:11Ilya.Kulakovcreate