Channels are meant to fallback to Object if the message is out of
order. Somewhere along the commit line this got removed despite the
issue still existing.
This has been a massive pain point for me personally due to the poor
design of the Enum class leading to the common use cases used in the
library being significantly slow. Since this Enum is not public facing
in terms of *creation*, I can only implement the APIs that are used
when *accessing* them.
This Enum is a drop-in replacement to the pre-existing enum.Enum class
except it comes with significant speed-ups. Since this is a lot to go
over, I will let the numbers speak for themselves:
In [4]: %timeit enums.try_enum(enums.Status, 'offline')
263 ns ± 34.3 ns per loop (7 runs, 1000000 loops each)
In [5]: %timeit NeoStatus.try_value('offline')
134 ns ± 0.859 ns per loop (7 runs, 10000000 loops each)
In [6]: %timeit enums.Status.offline
116 ns ± 0.378 ns per loop (7 runs, 10000000 loops each)
In [7]: %timeit NeoStatus.offline
31.6 ns ± 0.327 ns per loop (7 runs, 10000000 loops each)
In [8]: %timeit enums.Status.offline.value
382 ns ± 15.2 ns per loop (7 runs, 1000000 loops each)
In [9]: %timeit NeoStatus.offline.value
65.5 ns ± 0.953 ns per loop (7 runs, 10000000 loops each)
In [10]: %timeit str(enums.Status.offline)
630 ns ± 14.8 ns per loop (7 runs, 1000000 loops each)
In [11]: %timeit str(NeoStatus.offline)
253 ns ± 3.53 ns per loop (7 runs, 1000000 loops each)
In [12]: %timeit enums.Status('offline')
697 ns ± 8.42 ns per loop (7 runs, 1000000 loops each)
In [13]: %timeit NeoStatus('offline')
182 ns ± 1.83 ns per loop (7 runs, 10000000 loops each)
Embed edits are no longer special cased in the dispatch code, which
could lead to on_message_edit being called more often than it used to
be called. I am not sure on the general impact on that being removed.
Fixes#2195
Probably not a significant difference but might as well use it here.
The basic idea is to cache the getattr calls instead of repeatedly
doing it (since they're around 105ns on my machine). The dictionary
lookup is about 41ns on my machine.
The next step in speeding up library code some more should be in
the parser bodies themselves but that's a problem to tackle another
day.
This fix is long coming. For a long time due to the addition of a
global user cache, the on_member_update event would only have the
updated user in the very first dispatch due to a quirk in the reference
only being updated once.
In order to fix this issue two things had to change:
1. There had to be a new event, `on_user_update` to complement
the equivalent member event.
2. Unnecessary copies of User had to be removed to compensate for the
performance hit from the diffing.
While doing these two fixes I also re-evaluated some more unnecessary
copies done during the PRESENCE_UPDATE to add member case while
fetch_offline_members=False is set or due to chunking issues. The
number of copies was brought down from 2 to 1, discounting the original
Member creation. Unsure on the benefits of this one, however.
N.B: this doesn't change the pre-existing behaviour of on_member_update
Change `parse_message_delete_bulk` to not dispatch individual
`message_delete` events, and instead `bulk_message_delete`. Also make
`raw_bulk_message` delete and `raw_message_delete` have message
objects attached.
Fixes#1807
Most assets now return a new class named `Asset`. This allows for the
assets to be consistently saved via a `save` method instead of special
casing for `Attachment`.
`AppInfo` is no longer a namedtuple it is a fully documented dataclass,
as well as having the state attached to it.
Fixes#1997
Restrict the values accepted by comparisons with booleans to be actual
booleans.
Minor breaking of undocumented behaviour in permissions; the value to
set bits to must be booleans (as indicated by the type error thrown).
* type(x) is y is faster than isinstance(x, y)
* Re-arrange if-statements for common statements
* Drop handler getattr for most events that don't use it
This adds the following APIs:
* Guild.get_role
This removes the following APIs:
* Guild.role_hierarchy
To compensate for the removed APIs, Guild.roles is now a sorted list
based on hierarchy. The first element will always be the @everyone
role.
This speeds up access at the cost of some memory, theoretically.
large guilds that recieved GUILD_CREATE events prior to READY would
never dispatch guild_available/join. This is inconsistent with
smaller guilds and makes these events unreliable. Dispatch the
"delayed" guilds after they've been chunked, prior to ready.
This allows for internal changes in Discord to not cause a breaking
change every time something changes.
Also implements #1214 which adds guild_id to every event where
applicable.
This is a breaking change.
This is a massive breaking change.
* All references to "game" have been renamed to "activity"
* Activity objects contain a majority of the rich presence information
* Game and Streaming are subtypes for memory optimisation purposes for
the more common cases.
* Introduce a more specialised read-only type, Spotify, for the
official Spotify integration to make it easier to use.
This adds:
* CategoryChannel, which represents a category
* Guild.by_category() which traverses the channels grouping by category
* Guild.categories to get a list of categories
* abc.GuildChannel.category to get the category a channel belongs to
* sync_permissions keyword argument to abc.GuildChannel.edit to sync
permissions with a pre-existing or new category
* category keyword argument to abc.GuildChannel.edit to move a channel
to a category
This setting configures how long before a timeout event is emitted
internally and disconnects the websocket. Since some users were
experiencing issues with the gateway not responding, this should help
mitigate the issue for those with poor PCs.
New API change[1] will make it so CHANNEL_CREATE will keep getting
sent for private channels, so might as well avoid the overhead of
constantly creating the channel if we can avoid it.
[1]: https://github.com/hammerandchisel/discord-api-docs/issues/184
