refactor: Asynchronous cog/extension loading. #1132
Conversation
shiftinv
added
t: enhancement
Signed-off-by: lena <[email protected]>
Signed-off-by: lena <[email protected]>
| raise NotImplementedError(msg) | ||
|
|
||
| if not self._command_sync_flags._sync_enabled or self._is_closed or self.loop.is_closed(): | ||
| if not self._command_sync_flags._sync_enabled or self._is_closed: |
There was a problem hiding this comment.
Is this important? I can't remember why i removed this. I certainly wouldn't expect the (global) loop to be closed while the bot is running
| .. versionchanged:: 3.0 | ||
| The ``asyncio_debug`` parameter has been removed. Use :meth:`asyncio.loop.set_debug` directly. |
There was a problem hiding this comment.
Would it be worth to add this back and only deprecate it?
Also, it might be better to upgrade to Sphinx 7.3 first and change the directive to .. versionremoved:: instead.
| if connector: | ||
| try: | ||
| asyncio.get_running_loop() | ||
| except RuntimeError: | ||
| msg = ( | ||
| "`connector` was created outside of an asyncio loop, which will likely cause" | ||
| "issues later down the line due to the client and `connector` running on" | ||
| "different asyncio loops; consider moving client instantiation to an '`async" | ||
| "main`' function and then manually asyncio.run it" | ||
| ) | ||
| raise RuntimeError(msg) from None |
There was a problem hiding this comment.
I will remove this as this check only works when you create a dedicated loop for the connector but forget to set it as the global running loop, which is a very specific condition. I would rather not have this check at all (and document the requirement that was actually already there the whole time) or do a proper loop equivalency check, but the latter requires accessing private fields (<connector>._loop). Thoughts?
| @loop.setter | ||
| def loop(self, value: asyncio.AbstractEventLoop) -> None: | ||
| warnings.warn( | ||
| "Assigning to `Client.loop` is deprecated. Use `asyncio.set_event_loop()` instead.", |
There was a problem hiding this comment.
This isn't communicated in the docstring of @.loop because setters don't show up in the docs. Should the docstring be adjusted?
2 participants
Summary
Fixes #641
Refactors the codebase by removing loop sharing where possible and using
asyncio.get_running_loop()instead. The loop is still shared in places where the code runs on a separate thread likeKeepAliveHandlerandAudioPlayer. This means that the majority of the library can now assume that there is an event loop already running. Other changes are documented in changelog files.While the amount of breaking changes may seem horrific, practically most (if not all) use cases are trivial to fix: users will only need to paint a plenty of async/awaits here and there and possibly move any initialization logic from
on_ready, bot constructors, etc. intosetup_hook. For an example of migrating seetest_botchanges, or for a real-world example seethese three commits on my Avrae fork.Thanks to the addition of
Client.loopproperty bots that currently do something likebot.loop.create_taskwill not be affected by the changes (as long as that access happens after the bot is started, of course).While i have tried my best to test this in as many cases as possible, i would appreciate if someone could port their bot and see if there is anything suspicious happening.
Notably, i haven't yet tested voice sending features, even though they probably should be fine as-is.Tested it usingexamples/basic_voice.py, works like a charm now!I would also appreciate some hints on how/where to document this change, as i believe while it is easy to fix, it is still something that we need to make as many users as possible aware of even outside of the changelog.
As for the "Port #xxxx" commits: this initially started as ports of the according PRs to discord.py, but since the 4th or so commit work was done without "stealing" code from there. Not sure if there's anything legal needed to be done?
Checklist
pdm lintpdm pyright