Yep, that’s what I was specifically referring to – calling an async def/coroutine function synchronously using loop.run_until_complete(). Running a non-coroutine function synchronously is done just by calling it of course. asyncio.run() doesn’t really work as a higher-level version of loop.run_until_complete() in that context because it creates a new event loop every time instead of using the existing one. It’d be convenient to have a version that solely uses asyncio.get_running_loop() (raises when called outside of a running event loop) internally but doesn’t require the user to fetch a reference to the event loop. Assuming my interpretation of the long-term goal of removing the loop arg throughout asyncio is correct (see prev post for details), it seems to be in line with that.
In general, dealing with the event loop is also something that’s commonly mishandled by users, especially in the context of working with multiple threads. For example, you can quickly find yourself in the realm of undefined behaviors from passing around a reference of an event loop to other threads, since it’s intended for an event loop to be used only within the thread that it’s created. See Andrew’s “there be dragons” post.
I think that asyncio would be better off in terms of making it easier to work with if the majority of users didn’t have to worry about dealing with the event loop directly, and potentially getting it wrong in a way that’s not easy to detect.