| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Fixes #5923
|
| | |
|
| |
|
|
|
| |
This allows changing the connect flow and taking control of it without
relying on internal events or tricks.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This reverts commit a309088ae4be7c2e837e5d180822c0f9060fe86d.
A rate limited was added to this method after 5 years defeating the
purpose of it.
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Fixes #5756.
|
| | |
|
| |
|
|
|
|
|
|
| |
This seemed to have shaved a few microseconds:
10.8 µs ± 79.6 ns per loop → 8.53 µs ± 48.1 ns per loop
12 µs ± 613 ns per loop → 8.72 µs ± 30.2 ns per loop
With 100K loops each
|
| |
|
|
| |
Fix #5109
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #2510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original code was too aggressive in ensuring that the channel
positions are correct and within bounds. Unfortunately, for Discord
this number is merely a guess and there can be gaps that cause the
position number to be greater than the number of channels currently
in that sorting bucket.
One such example of this is when a channel is deleted and created. When
this happens, the positions are not updated (presumably because Discord
considers this to be too expensive). Sadly this means that if a user
were to create a channel, delete a channel, and then create another one
then there will be gaps in the position sequence.
More concretely, consider the following example:
Channels with position [0, 1, 2, 3, 4]. A new channel is created so it
inherits the maximum position giving us [0, 1, 2, 3, 4, 5]. We delete
a channel that's smaller than the maximum so our list now looks like
[0, 1, 2, 4, 5]. Next time we create a channel we will further
increment the gap, giving us [0, 1, 2, 4, 5, 6]. If a user would want
to move the channel with position 4 to be after position 6 (so in this
case that value would 7) then the library would erroneously raise an
error because it assumed too much about the data integrity.
Luckily, the library upon actually doing the request fixes the channel
positions so everything goes back to normal like it was intended. That
is to say, [0, 1, 2, 3, 4, 5].
|
| | |
|
| | |
|
| |
|
| |
The code before this returned None when there is no category.
|
| | |
|
| |
|
|
| |
This allows users to check whether or not the permissions for a Guild Channel are synced with the permissions for its category. Discord automatically syncs the permissions when the overwrites are equal so just checking if the two overwrites are equal will determine if they are synced.
|
| | |
|
| |
|
|
| |
Fix #2290
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fix #2185
|
| | |
|
| | |
|
| |
|
|
| |
Fix for #2189
|
| |
|
|
|
| |
* Replaced instances of 'return an' with 'returns an'
* fixed pluralization errors
|
| | |
|
| |
|
|
| |
Apparently some people get confused by this.
|
| |
|
|
| |
Fixes #2093
|
| |
|
|
| |
Refactor delete_after kwargs to use new delay kwarg
|
| |
|
|
|
| |
This has potential for data loss as a consequence of how the function
works.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Fix #2016
|
| |
|
|
| |
Convert list comprehension to genexpr
|
| |
|
|
| |
Fixes #2002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added access to:
* `/users/@me/guilds`
* `/guilds/{guild_id}`
* `/guilds/{guild_id}/members/{member_id}`
BREAKING CHANGE:
* `get_user_info` -> `fetch_user_info` to match naming scheme.
Remove useless note
Remove `reverse` and corresponding documentation
Update documentation to reflect #1988
Rename `get_` HTTP functions to `fetch_`
Breaking Changes:
* `get_message` -> `fetch_message`
* `get_invite` -> `fetch_invite`
* `get_user_profile` -> `fetch_user_profile`
* `get_webhook_info` -> `fetch_webhook`
* `get_ban` -> `fetch_ban`
Fix InviteConverter, update migrating.rst
Rename get_message to fetch_message
|
| | |
|
| |
|
|
| |
Fix #1809
|