Consider the following code:

import asyncio

q = asyncio.Queue()

async def main():
    await asyncio.gather(q.put(1), q.get(1))

asyncio.run(main())


This code just hangs since run() creates a loop but queue is bound with another (default) event loop.

The error is confusing and hard-to-debug.

We should raise a warning at least for the case; start from DeprecationWarning and make the system stricter later.

asyncio/locks.py is also affected since it has first-class classes (classes that instantiated by a user directly without factories).

Yes.

As a remedy for this particular problem we can add checks here and there comparing `asyncio.get_running_loop()` and `self._loop`.  Performance will suffer a bit but the usability will greatly improve.

I have a different feeling: we should start raising deprecation for asyncio.Queue() if it is created without running event loop.

It required `get_event_loop()` and `loop.is_running()` checks.

Later the pair can be replaced with `get_running_loop()`.

I think no check at awaiting time is needed; we never do it for other asyncio parts.  Just control of the loop at creation time is enough; if the object is created inside a running loop the sane code will use it with this loop context always.

At least it is my learned lesson from aiohttp development.

The current implementation of asyncio.run() is focused quite a bit on one-shot use. After the call returns, the default event loop is even gone: calling asyncio.get_event_loop() gives "RuntimeError: There is no current event loop in thread 'MainThread'."

It would be nice if asyncio.run() uses the default loop if it's available (and not running), and that the default loop remains intact after the call returns. 

This way multiple calls to asyncio.run() that all use the default loop are supported, maybe using an asyncio.Queue (or whatever) across these calls---attaching everything to the same (default) loop.

I find this very useful, for instance when writing unit tests.

> It would be nice if asyncio.run() uses the default loop if it's available (and not running), and that the default loop remains intact after the call returns. 

Unfortunately it's not possible to implement that reliably and without a bunch of surprising behaviors.

Also, if you want the loop to be intact after asyncio.run, it means that you would not want to close it;that would defeat the purpose of asyncio.run.

Well, I'm basically using a run method defined as a shorthand for self.loop.run_until_complete (without closing loop, reusing it throughout). It would be nice if asyncio.run could simply be used instead, but I understand you're saying this is easier said than done, which is fine with me. Thanks.

> Well, I'm basically using a run method defined as a shorthand for self.loop.run_until_complete (without closing loop, reusing it throughout). It would be nice if asyncio.run could simply be used instead, but I understand you're saying this is easier said than done, which is fine with me. Thanks.

Yes. `asyncio.run()` is similar to `loop.run_until_complete()` but adds some guarantees + sane setup/cleanup. If we strip proper cleanup then there's no point in `asyncio.run()`.  So using `loop.run_until_complete()` is totally fine when you want to preserve the event loop between runs.

I'm pretty happy with asyncio.run() functionalit.

I used run() for the bug demonstration, but the example can be rewritten easily without this function.

The problem is not in run() but in an object lifecycle. Implicit loop creation plus module-level initialization provides a pretty big set of ways to shoot in the foot :)

Hi, I'm a new contributor and this issue looks like an interesting enhancement: is there any consensus forming on what we want to limit to e.g. raising depreciation warnings when these first-class classes are created without running event loop?

Hi, 

@asvetlov are you thinking something like the patch attached?

It is also generating deprecation warning:

> /opt/python/3.8.0/lib/python3.8/asyncio/queues.py:48: DeprecationWarning: The loop argument is deprecated since Python 3.8, and scheduled for removal in Python 3.10.
>   self._finished = locks.Event(loop=loop)

Fixed by #42392