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.
Reaction objects with custom Emoji are partial. If we know of this Emoji
(can find it on this client) then inject it. Otherwise, leave it as a
hollow Emoji. We can still react with a hollow Emoji, but can't get other
metadata about it.
- Properly support 'after' alone
- Properly support both 'before' and 'after'
- Add optional 'reverse' parameter to sort messages oldest->newest to
1) provide a sorted result set for 'after'
2) give flexibility when using both 'before' and 'after'
This is a breaking change. Code will still work in Python 3.4 as-is but
if you use Python 3.5 you will have to change your code to the new
`async for` syntax as the older version is not supported in 3.5.
On the other hand, this comes with performance improvements if you use
Python 3.5 as it will lazily load 100 message chunks on an as needed
basis rather than loading all messages in one go.
