This change makes it more so that `Loop.stop()` gracefully makes the
current iteration the final one, by waiting AND THEN returning.
The current implementation is closer to `cancel`, while also not.
I encountered this because I was trying to run a
`@tasks.loop(count=1)`, and inside it I print some text and change the
interval, and in an `after_loop`, I restart the loop.
Without this change, it immediately floods my console, due to
not waiting before executing `after_loop`.
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.
This unfortunately required splitting the types into two. This led to
a lot of unfortunate code duplication that I didn't really enjoy
writing.
The new design allows users to pass an authentication token to make
webhook requests without the webhook token and allows to finally
edit the webhook channel.
The new design also uses a contextvar to store rate limiting
information so multiple instances or recreating instances no longer
clears the ratelimiting state since it's now essentially a "global"
object.
Closes#6525, closes#6662, closes#2509, closes#1761
This allows for DMChannels to work without falling back to the
Object error case since there is enough information to build a pseudo
DMChannel object.
This is a breaking change since it changes the type of
DMChannel.recipient to Optional[User] for when this faux object is
created.
