Restrict the values accepted by comparisons with booleans to be actual
booleans.
Minor breaking of undocumented behaviour in permissions; the value to
set bits to must be booleans (as indicated by the type error thrown).
Use bare raise statement when reraising the exception that occured, and
remove unused exception variables. Also remove a pointless exception
handler in discord.opus.
* type(x) is y is faster than isinstance(x, y)
* Re-arrange if-statements for common statements
* Drop handler getattr for most events that don't use it
Introduce a new internal type, SnowflakeList, which has better memory
footprint over a regular list or set of roles. It is suspected that
there will be a 9x reduction of memory for every Emoji instance and a
48 byte saving per Member instance. However, these savings will
probably only be evident on larger bots.
As a consequence of this change, Member.roles is now computed lazily.
Currently I am not sure if I want to do the initial sorting on the
SnowflakeList for Member, as this comes with a O(n log n) cost when
creating a Member for little purpose since SnowflakeList.has is not
overly relied on. If CPU time becomes an issue this might change.
This adds the following APIs:
* Guild.get_role
This removes the following APIs:
* Guild.role_hierarchy
To compensate for the removed APIs, Guild.roles is now a sorted list
based on hierarchy. The first element will always be the @everyone
role.
This speeds up access at the cost of some memory, theoretically.
Original code by zephyrkul.
This new parsing mode allows for backtracking in case of failure
when a typing.Union[..., NoneType] or a typing.Optional[...] is used.
This means that if a type would fail to parse, the view is undo'd to
a previous state, passing the default parameter to the callback, and
then continuing on the next parameter as if nothing had happened.
In the docs, it says ``Note that bot accounts can only edit custom emojis they own.``
But after testing a bit. My bot was able to edit emojis in any guild that had the permissions `manage_roles`. Even if the bot didn't own the guild. Or was the original emoji uploader.
And I don't see any mentions of this in the API server or in the documentation. So I'm unsure how this ended up in here. It's possible I am misunderstanding the whole note. My bad if that's the case.
If the bot has access to the emoji, you can pass anything for its name
and it will work fine. The name is only required to be correct when
adding a reaction where you do not have access to the emoji,
all other cases ignore the name.
