Evaulate the custom Enum class #104
Description
Enums have been greatly debated, and regularly come back as a discussion topic:
- https://canary.discord.com/channels/881207955029110855/881735314987708456/1392179636800196871
- https://canary.discord.com/channels/881207955029110855/881735314987708456/1413517013829029988
An a couple others I can't find.
The question comes from the fact that py-cord inherited from discord.py a custom Enum-like class, which is being used throughout the library in place of enum.Enum.
The reasoning for this choice has been, notably, performance, as well as support for unknown values by default.
The performance gains of this have been criticized for being irrelevant, especially with newer python versions.
A specific issue that has been brought up multiple times, and which seems to be the main concern, is the use of TYPE_CHECKING to falsely type the custom Enum class to be the actual built-in enum.Enum, which can (and has) lead library users and developers to falsely assume it to be of type enum.Enum even though it wasn't and some seemingly unpredictable and or weird behavior.
Another issue worth mentioning is the non-null quantity of code to maintain (and which remains as of today old and unmaintained technical debt) the custom Enum class brings, when an almost 1-1 equivalent is present in the standard library.
Given the above, an assessment should be made to consider whether usage of the custom Enum class should be dropped, and what to use instead if that is the case. enum.IntEnum has been proposed, which seems to be the closest alternative performance wise and in an effort to represent values closer to what they look like in the Discord API, most often simply ints.
Another proposed alternative is the subclassing of enum.Enum to implement the additional features of the current custom Enum class.
While I want to stay as objective as possible here, note that my personal opinion is in favor of dropping the custom Enum class to be replaced with IntEnum.