Author aeros
Recipients aeros, asvetlov, yselivanov
Date 2020-11-18.00:08:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1605658103.42.0.485269467128.issue42392@roundup.psfhosted.org>
In-reply-to
Content
> Oh my.  FWIW I think that we need to implement this differently. I don't think it matters where, say, an asyncio.Lock was instantiated. It can be created anywhere. So IMO its __init__ shouldn't try to capture the current loop -- there's no need for that. The loop can be and should be captured when the first `await lock.acquire()` is called.

That's good to know and I think more convenient to work with, so +1 from me. I guess my remaining question though is whether it's okay to `await lock.acquire()` on a single lock instance from multiple different running event loops (presumably each in their own separate threads) or if there's a need to restrict it to only one event loop.

> I'm writing a piece of code right now that would need to jump through the hoops to simply create a new `asyncio.Lock()` in a place where there's no asyncio loop yet.

From what I've seen of asyncio user code, it seems reasonably common to create async primitives (lock, semaphore, queue, etc.) in the __init__ for some class prior to using the event loop, which would fail with usage of `get_running_loop()` in the __init__ for the primitives. So, if it's not an issue to wait until accessing the event loop until it's actually needed (e.g. in the lock.acquire() or queue.get/put()), I think we should definitely try to be conscious about when we call `get_running_loop()` going forward to ensure we're not imposing arbitrary inconveniences on users.
History
Date User Action Args
2020-11-18 00:08:23aerossetrecipients: + aeros, asvetlov, yselivanov
2020-11-18 00:08:23aerossetmessageid: <1605658103.42.0.485269467128.issue42392@roundup.psfhosted.org>
2020-11-18 00:08:23aeroslinkissue42392 messages
2020-11-18 00:08:23aeroscreate