This fix is long coming. For a long time due to the addition of a
global user cache, the on_member_update event would only have the
updated user in the very first dispatch due to a quirk in the reference
only being updated once.
In order to fix this issue two things had to change:
1. There had to be a new event, `on_user_update` to complement
the equivalent member event.
2. Unnecessary copies of User had to be removed to compensate for the
performance hit from the diffing.
While doing these two fixes I also re-evaluated some more unnecessary
copies done during the PRESENCE_UPDATE to add member case while
fetch_offline_members=False is set or due to chunking issues. The
number of copies was brought down from 2 to 1, discounting the original
Member creation. Unsure on the benefits of this one, however.
N.B: this doesn't change the pre-existing behaviour of on_member_update
if len(data) < 100, either limit was less than 100, or we ran
out of results, in both cases, we should terminate the lookup.
This fixes, e.g., hangs in audit_logs(limit=999999), and will
reduce the number of fetch calls for any case where limit is
greater than the number of results. (Prior, would just kinda
loop calling audit-logs)
rename reverse to oldest_first and remove cases where messages would
be ordered differently from the order we fetch audit log entries,
similar to HistoryIterator
rename reverse -> oldest_first, which is more obvious what it does.
Then, honor it entirely - if you specify no `after` endpoint, we default
to the beginning of message history, similar to how `before` defaults to
the end of message history.
This is a breaking change, and will change the behavior of any iterator
that previously would have been returning messages in a weird order for
limits over 100
`for msg in history(reversed=True, limit=300)` would return the newest
300 messages, in a messed up order (100..0, 200..100, 300..200).
`for msg in history(oldest_first=True, limit=300)` will now return the
oldest 300 messages in order. And so on.
`for msg in history(after=msg)` is unchanged, this previously would
return the oldest 100 messages after `msg`, oldest->newest order, and
still will.
Certain decorators and functions expect coroutines and raise an
exception when this is not met. Change these to raise the appropriate
TypeError since they can't actually be handled by the user gracefully
anyway.
This allows for URLs to be left alone since they can include markdown
characters and allows for total escaping of all markdown characters
by default to prevent some form of data manipulation.
Rapptz
Lorenzo
apple502j
NCPlayz
Steve C
Dante Dam
Imayhaveborkedit
Vexs
Daniel
khazhyk