This affects:
* Member.add_roles
* Member.remove_roles
This is the main attempt of fixing long standing bugs like #56. Since
cache consistency is too hard to ask for due to eventual consistency
and this generally being one of the only main roadblocks that the
cache ruins, it's best to just implement it in terms of the atomic
endpoint instead.
Fixes#56
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.
This should allow an easier way to query the Discord protocol gateway
latency, defined by the difference HEARTBEAT_ACK between and the last
sent HEARTBEAT.
In some cases, the Discord provided role_mentions and mentions array
would be empty, such as wrapping a mention with a backtick or
other frivolous characters. Since we want to completely nullify
mentions, we should not rely on the Discord provided arrays and instead
use and resolve the IDs from the content itself.
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.
static_format will only apply to static (not animated) avatars. Makes
it easier to grab gif-or-'format' of an avatar. Defaults to 'webp'
This is for a similar usecase to avatar_url_as(format=None), except
one can specify the non-animated format, instead of always using
webp.
add User.avatar_is_animated property.
add validation for avatar_url_as, since invalid arguments result in
a url which will return 415, which can be confusing for a user. (They
just see a blank page)
Discord accepts size=16-2048, but images cap at 1024px, so accept 16-1024
Discord accepts "jpg", "jpeg", "png", "gif", and "webp", *unless* the
avatar is not animated, in which case "gif" is not supported. :\
Raise after loop completes without returning with most recent values
for r, data. This is a bit less fragile than checking tries < 4, since
changing the retry count requires changing values in multiple places.
(There seemed to already be handling in the 502 retry, tries <= 5,
which always evaluated to true, e.g.)
Previously, once out of retries, we would always return None without
raising.
This won't NameError so long as we make at least one HTTP request.
