This has been a massive pain point for me personally due to the poor
design of the Enum class leading to the common use cases used in the
library being significantly slow. Since this Enum is not public facing
in terms of *creation*, I can only implement the APIs that are used
when *accessing* them.
This Enum is a drop-in replacement to the pre-existing enum.Enum class
except it comes with significant speed-ups. Since this is a lot to go
over, I will let the numbers speak for themselves:
In [4]: %timeit enums.try_enum(enums.Status, 'offline')
263 ns ± 34.3 ns per loop (7 runs, 1000000 loops each)
In [5]: %timeit NeoStatus.try_value('offline')
134 ns ± 0.859 ns per loop (7 runs, 10000000 loops each)
In [6]: %timeit enums.Status.offline
116 ns ± 0.378 ns per loop (7 runs, 10000000 loops each)
In [7]: %timeit NeoStatus.offline
31.6 ns ± 0.327 ns per loop (7 runs, 10000000 loops each)
In [8]: %timeit enums.Status.offline.value
382 ns ± 15.2 ns per loop (7 runs, 1000000 loops each)
In [9]: %timeit NeoStatus.offline.value
65.5 ns ± 0.953 ns per loop (7 runs, 10000000 loops each)
In [10]: %timeit str(enums.Status.offline)
630 ns ± 14.8 ns per loop (7 runs, 1000000 loops each)
In [11]: %timeit str(NeoStatus.offline)
253 ns ± 3.53 ns per loop (7 runs, 1000000 loops each)
In [12]: %timeit enums.Status('offline')
697 ns ± 8.42 ns per loop (7 runs, 1000000 loops each)
In [13]: %timeit NeoStatus('offline')
182 ns ± 1.83 ns per loop (7 runs, 10000000 loops each)
The way the command cooldown works is using a windowed way of doing it.
That is, if we have a cooldown of 2 commands every 30 seconds then if we
do a single command, we have 30 seconds to do the second command or else
we will get rate limited. This more or less matches the common
expectations on how cooldowns should be.
These cooldowns can be bucketed up to a single dimension of depth for
a per-user, per-guild, or per-channel basis. Of course, a global bucket
is also provided. These cannot be mixed, e.g. no per-channel per-user
cooldowns.
When a command cooldown is triggered, the error handlers will receive a
an exception of type CommandOnCooldown with proper information regarding
the cooldown such as retry_after and the bucket information itself.
