* Add missing versionadded strings for v1.3
* Add missing versionchanged string for Message.edit
* Consistently use versionadded for attributes
* Consistently use versionchanged for parameters
* Use versionchanged for Bot.is_owner
* Fix references in v1.3 changelog
* Improve grammar in v1.3 changelog
This includes raw events (which didn't have any) and a few other
types that were missing them. Upon review some more useful fields were
added to the repr output which would be more useful during debugging.
The Asset PR (be227ebcf0c8bad6b56798339b5414b8da414dc0) changed some namedtuple-deriving
classes to object-deriving classes, which meant that the free __repr__ provided by namedtuple
was removed
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
Introduce a new internal type, SnowflakeList, which has better memory
footprint over a regular list or set of roles. It is suspected that
there will be a 9x reduction of memory for every Emoji instance and a
48 byte saving per Member instance. However, these savings will
probably only be evident on larger bots.
As a consequence of this change, Member.roles is now computed lazily.
Currently I am not sure if I want to do the initial sorting on the
SnowflakeList for Member, as this comes with a O(n log n) cost when
creating a Member for little purpose since SnowflakeList.has is not
overly relied on. If CPU time becomes an issue this might change.
In the docs, it says ``Note that bot accounts can only edit custom emojis they own.``
But after testing a bit. My bot was able to edit emojis in any guild that had the permissions `manage_roles`. Even if the bot didn't own the guild. Or was the original emoji uploader.
And I don't see any mentions of this in the API server or in the documentation. So I'm unsure how this ended up in here. It's possible I am misunderstanding the whole note. My bad if that's the case.
If the bot has access to the emoji, you can pass anything for its name
and it will work fine. The name is only required to be correct when
adding a reaction where you do not have access to the emoji,
all other cases ignore the name.
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.
The global emoji cache still managed to somehow cause memory leaks. By
storing IDs directly and lazily evaluating them when needed this
essentially removes all strong references to Guild objects which would
cause an explosion in memory usage.
WeakValueDictionary cleans up too late and brings too little benefit.
Also clean up the state when the first READY is encountered for
AutoShardedClient and when any READY is encountered in regular Client.
