gh-94597: add asyncio.EventLoop

[graingert]

• Issue: deprecate the asyncio child watchers system #94597

---

📚 Documentation preview 📚: https://cpython-previews--110723.org.readthedocs.build/

[graingert]

This allows running asyncio coroutines without interacting with the policy system eg:

asyncio.run(main(), loop_factory=asyncio.EventLoop)
# no need to call asyncio.set_event_loop_policy(None) !

this allows code to run without interfering with a policy that has been set in one location especially one that expects asyncio.set_event_loop() to be called after every invocation of asyncio.new_event_loop()

[gvanrossum]

Do you intend this to be merged before or after the deprecations PR?

[gvanrossum]

I think this ought to explain that it's an alias for one of the above classes, and that it's the one used by default, and that it's selected the way described above (L1689-90). "Uses" doesn't even explain that it's a subclass of AbstractEventLoop.

Maybe we should be less specific about how the default is selected, and probably whatever we say about it should be only said once, but it should be made clear that this class is the default, and the default is this class.

[graingert]

maybe something like this? The other classes don't explain that they are subclasses of AbstractEventLoop, should that be explained in ProactorEventLoop and SelectorEventLoop?

Suggested change

	Uses the most efficient available event loop for the given
	platform.
	Uses the most efficient available event loop for the given
	platform.
	It is an alias for :class:`SelectorEventLoop` on Unix and :class:`ProactorEventLoop` on Windows.

[gvanrossum]

Not quite. I don't like any sentence describing a class object starting with "Uses". Classes are nouns, and the description should explain what the class is, not what it does. Also, the current algorithm for choosing a default is now specified in two places. I think it should be specified only here (and the earlier text should be changed to claim that EventLoop is the class used by default).

It's also a good idea to clarify that both concrete classes are subclasses of AbstractEventLoop (but if you're tired of going around in review you can skip that).

[graingert]

ok I've pushed a change with some doc tweaks

[graingert]

Do you intend this to be merged before or after the deprecations PR?

I don't mind what order the PRs go in - I plan a cleanup PR for the CPython test suite removing redundant calls to set_event_loop_policy(None) once asyncio.EventLoop is available for use in asyncio.run calls

[gvanrossum]

Thanks! Merging now.

[vstinner]

It is an alias to :class:SelectorEventLoop on Unix and :class:ProactorEventLoop on Windows.

Well. In the early days of tulip/asyncio, there were more choices, and we didn't know how third-party projects will inherit/override these classes. Now I agree that asyncio.EventLoop is the way to go, it's easier to remind, it's more explicit, and it's easy to guess what is it (SelectorEventLoop or ProactorEventLoop).