I tested it just now, and manage_guild is not the permission you need to
fetch invites from a given channel. You need manage_channels.
Note that this isn't the same as Guild.invites(), which DOES use
manage_guild.
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
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].
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.
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.
Nihaal Sangha
Misa
Nadir Chowdhury
Rapptz
PikalaxALT
webtax-gh
Michael
Xua
Duck
Dan Hess
khazhyk
parafoxia
Sebastian Law
jack1142
CapnS
Devon R
apple502j
Capn
Xua
Ehren Julien-Neitzert
DevilXD
Vexs