| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Fixes #974
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
In case you want to have some external restart loop.
|
| | |
|
| |
|
|
| |
/dist.py:352: UserWarning: Normalizing '1.0.0a1402+0965847' to '1.0.0a1402+965847'
|
| | |
|
| | |
|
| |
|
| |
Maintains support for < 3.4.4
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When accessing the latencies property on an AutoShardedClient when none of shards are ready, we get a ZeroDivisionError. An example of this can be seen here.
```py
class StatsBot(commands.AutoShardedBot):
def __init__(self):
super().__init__(command_prefix=None)
self._add_commands()
def _add_commands(self):
'''Adds commands automatically'''
for name, attr in inspect.getmembers(self):
if isinstance(attr, commands.Command):
self.add_command(attr)
```
When iterating through this custom client's it accesses the latencies property when no shards are ready, therefore it raises the error. A quick fix for this would be to return None if no shards are ready.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Was returning None when User.avatar was None
|
| | |
|
| |
|
|
|
|
| |
local version identifier seems to be the only PEP440
way to add arbitrary string to the version. Makes
pip stop complaining about invalid version label.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This time with less bugs. It turned out that the crash was due to a
synchronisation issue between the pending reads and the actual shard
polling mechanism.
Essentially the pending reads would be cancelled via a simple bool but
there would still be a pass left and thus we would have a single
pending read left before or after running the polling mechanism and
this would cause a race condition.
Now the pending read mechanism is properly waited for before returning
control back to the caller.
|
| | |
|
| |
|
|
| |
This reverts commit 462191a08b5b2efb83f5bc32935dc546d35a744b.
|
| | |
|
| |
|
|
|
|
|
|
| |
None case:
344ns ± 24.4ns -> 49.9ns ± 1.39ns
Valid case:
128ns ± 2.76ns -> 42.7ns ± 0.459ns
|
| |
|
|
|
| |
Requiring a full blown Context might be a bit overkill considering
we only use a single attribute from it.
|
| | |
|
| |
|
|
|
| |
This allows us to check if we are rate limited without
creating a new cool-down window for the command.
|
| |
|
|
|
| |
Clarifies that bot accounts can only interact with emoji they have
created.
|
| |
|
|
|
|
| |
Due to a recent change in the Discord API, bots can now create
guild-specific emoji, so I've removed the parts of the documentation
referencing this restriction.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #811
|
| |
|
|
|
|
| |
Should make the category-only edit cases more straightforward since
it does not rely on other guilds in the cache, outside of the category
itself.
|
| |
|
|
|
|
|
| |
This should fix issues when doing a `abc.GuildChannel.edit` immediately
afterwards and then when the corresponding CHANNEL_CREATE comes in the
channel instance should hopefully be overwritten by the authoritative
figure, the WebSocket.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is suggested to prevent spamming the console unnecesarilly.
Info should be used to output information to the user that is important, but
not a warning or an error. If I am bundling a bot as a modular package then
it doesn't really make sense to spam their console with every time a coroutine
is subscribed to, as it likely will not mean anything to the user. If they are
interested in this, it would make more sense to just to enable debugging first.
I have made this change, as I am writing a wrapper for this library for a
private project, and that will handle dispatching events, thus, I do not
need a prompt for each event that is subscribed to in this module outside of
DEBUG. Currently, with logging set to INFO, I am getting 47 lines reading:
INFO:discord.client:coroutine has successfully been registered as an event
...being output as my bot starts, and without having to disable INFO logging
altogether, I am currently having to temporarily change the verbosity of the
logger as the events are initialised, which is not desirable as it could
potentially cover up any other INFO messages that would be useful to have
output.
Using a filter seems like a bit of a hacky workaround. If this isn't acceptable
then another alternative would be to add a parameter to the constructor of
discord.Client to enable or disable printing this information.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|