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.
having them appear in the docs ordered by their internal number
is not useful to the user. Sorting them by name
allows one to more quickly locate a voice region in the docs.
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.
The previous usage of `typing.get_type_hints` caused issues as it would
incorrectly decide to convert annotations into their equivalent
`typing` form -- which is not what we want to happen here.
Due to some use-cases about how setting `Command.callback` work and
the amount of moving parts that have changed due to this patch, it is
probably better to refactor the way it is set so users can have this
use-case handled transparently for them.
The method log of Logger has never been documented as being a part of
the standard logging module. It was renamed to warning when the module
was included in the standard library, but the old name was kept for
backward compatibility.
Rapptz
zephyrkul
Vexs
MusicOnline
Episword
Jeremy Zhang
Tarek1337
ItWasAllIntended
BeatButton
Toby Harradine
bmintz
Carl Groth
Chris
Bryan Forbes
Hornwitser
orlnub123
SilicalNZ
mental
Toby Harradine
MaximusPX