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)
Rapptz
991140eebe