Berry Schoenmakers

I wonder a bit how much existing code will be broken by this change in Python 3.12? If the deprecation warning in Python 3.10-11 remains unnoticed (like for me, until...

Thanks as well. It's good to have something next to `asyncio.get_running_loop()` because that can be only be called from a running loop;) For lower-level usage of `asyncio`'s event loops, accessing...

Thanks, these are interesting options, indeed for Python 3.11+ which will have this new Runner class. Using a `loop_factory()` does not seem preferable because `asyncio.new_event_loop()` is still called, which may...

The backdrop for the use case is a bit extensive, so I'll try to extract the relevant points for your discussion as directly as possible. The perspective is that of...

Right, thanks. The Runner class was also suggested by @graingert above. Indeed, this should give enough flexibility to set an exception handler and more generally one gets direct access to...

... trying this out was effortless. Double checked things, and turns out that replacing ```python self._loop = asyncio.get_event_loop() # cache event loop ```` with ```python self._loop = asyncio.Runner().get_loop() # cache...

Nice, thx, that makes it work combined like this: ```python self._loop = asyncio.mixins._LoopBoundMixin()._get_loop() if self._loop is None: self._loop = asyncio.Runner().get_loop() ``` Now it also works when a loop is already...

But I actually want to create Futures attached to a (the?) not-yet running loop. At least that's what I've been doing so.

I would prefer to avoid that kind of approach. But currently in 3.11 things like `loop = asyncio.Runner().get_loop(); asyncio.Future(loop=loop)`, where `loop` is not running work without (deprecation) warning. So, isn't...

An issue with refactoring along these lines is that there's also the other case that run() is not called at all. Namely, if top-level await is supported like in the...