Segments where readability was hampered were fixed by appropriate
format skipping directives. New code should hopefully be black
compatible. The moment they remove the -S option is probably the moment
I stop using black though.
This is a breaking change.
This does the following transformations, assuming `asset` represents
an asset type.
Object.is_asset_animated() => Object.asset.is_animated()
Object.asset => Object.asset.key
Object.asset_url => Object.asset_url
Object.asset_url_as => Object.asset.replace(...)
Since the asset type now requires a key (or hash, if you will),
Emoji had to be flattened similar to how Attachment was done since
these assets are keyed solely ID.
Emoji.url (Asset) => Emoji.url (str)
Emoji.url_as => removed
Emoji.url.read => Emoji.read
Emoji.url.save => Emoji.save
This transformation was also done to PartialEmoji.
* 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 (be227ebcf0) 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.
