Message.timestamp is replaced with Message.created_at. This commit
also affects how MESSAGE_UPDATE is handled by only assuming that two
keys are provided rather than overwriting data with missing keys.
Reaction objects with custom Emoji are partial. If we know of this Emoji
(can find it on this client) then inject it. Otherwise, leave it as a
hollow Emoji. We can still react with a hollow Emoji, but can't get other
metadata about it.
Reactions can be be standard emojis, or custom server emojis.
Adds
- add/remove_reaction
- get_reaction_users
- Messages have new field reactions
- new events - message_reaction_add, message_reaction_remove
- new permission - add_reactions
This includes `Client.pin_message`, `Client.unpin_message` and
`Client.pins_from`. This also adds the `Message.pinned` attribute
to the `Message` object.
Replaced server member lists, channel lists, and private channel lists
with dicts. This allows O(1) lookups and removes (previously it would be
an O(N) operation to lookup or remove). I did pretty extensive testing
and benchmarking to compare the performance of using lists vs using
dicts. Iterating through lists to find an item is only faster in the
average case for extremely small lists (less than 3 items). For 100
items, using a dict is about 10 times faster on average (and about 100
times faster for 1000 items). The overhead in dicts is in memory usage
and initial creation time. Creating and populating a dict is about 2 to
3 times slower than creating and appending items to a list. However this
cost is still tiny. For 1000 items this equates to about a 70
microsecond difference (on an i7 CPU) for populating the entire dict.
The memory overhead for a dict (compared to a list) is about 25-60 KB
per 1000 items (can vary depending on dict resizing).
Originally I wanted to use OrderedDicts to presereve order, but in my
testing OrderedDicts have about 6x the memory overhead compared to
normal dicts.
A lot of the expensive getters were transformed into cached properties
instead. A lot of things that were properties were transformed into
properties as well.
This was to allow for basic checks such as message.channel.is_private
to succeed at the very least. It is a very small mitigation and not
perfect since it doesn't have every attribute that PrivateChannel
itself has. However you could retrieve the user info through the
Message.author attribute.
Rapptz
khazhyk
Zeta
Steven Berler