As a `bool` converter is treated differently from other callable (basic) converters, the explanatory docs should outline that it is evaluated differently from a simple type cast, and what logic is used in determining how the content is evaluated.
The Inline Advanced Converters are a logical extension of the Advanced Converters subject, and as such should be placed under that section without an unrelated converter type breaking the two up.
It turns out that events created in an eval command also cause
the issue described in #1506.
Ensure that events we remove are part of a module as well.
Also performs minor comment maintenance
("x", "first y", "then z") -> ("x", "y", "z")
Basically Discord retrieves the data like
`artist1; artist2; artist3` and when you split only by `;` the results
will be: `[artist1, " artist2", " artist3"]`
`Webhook.send()` now accepts a `files` kwarg holding a list of `File`
objects, which are included in the HTTP request as `file1`, `file2` and
so on.
This is an undocumented feature of the Discord API, but is analogous
with the client's sending of messages with multiple files.
Remove the old and slow Member._copy implementation that was left over
by accident in 095f0ec. Since it was defined later it overrode the new
implementation and rendered it moot.
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.
