Kyle Stanley <aeros...@gmail.com> added the comment:
> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42392> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
