This bug was kind of a long one to figure out, as per #1918 documents
the issue had to do with subcommands but the actual adventure in
finding this one was a long one.
The first problem was that Command.cog was for some reason None, which
indicated that a copy was happening somewhere along the way. After some
fiddling I discovered that due to the copies of `Cog.__cog_commands__`
the groups pointed to out-dated versions that got overriden by the new
copies.
The first attempt at fixing this was straightforward -- just remove the
subcommand from the parent and replace it with the newer reference that
we just received. However, this ended up not working due to a strange
mystery where the subcommand being invoked was neither the original
copy nor the new copy residing in `Cog.__cog_commands__`.
Some more investigation later pointed out to me that a copy occurs
during the `Group.copy` stage which calls `Command.copy` for all its
subcommands. After spotting this out I had realised where the
discrepancy comes from. As it turns out, the subcommand copy that was
being invoked was actually a stale one created from `Group.copy`.
The question remained, how come that one was being called? The problem
stemmed from the fact that when the subcommand was copied, the parent
reference pointed to the old parent. Since the old parent was the one
that was getting the new reference, it went practically untouched. This
is because the calling code fetches the child from the parent and the
old parent is nowhere in the call chain.
To fix this issue we needed to update the parent reference, and in
order to do that a temporary lookup table is required pointing to the
latest copies that we have made.
Thus ends a 3.5 hour bug hunting adventure.
This adds the following information.
* `PartialInviteGuild` to replace `Object` patching
* `PartialInviteChannel` to replace `Object` patching
* Invite.approximate_member_count and Invite.approximate_presence_count
The new partial objects provide better documentation on what is
expected when you fetch random invites.
Fixes#1830
* 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.
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.
Rapptz