Amend PEP 586 to make `enum` values subtypes of `Literal`

Typing
11

I still think it’s a shame that this is not possible. What if we just made it a convention that IntEnum and StrEnum behave as expected, by:

  • annotating revelant methods like __eq__, __add__ and __bool__ with @final in typeshed / cpython itself.
  • This shouldn’t break any existing code, as the decorator does nothing at runtime.
  • Users that do want to override these methods, and not get typing errors, still can manually subclass enum.Enum and int/str instead of subclassing IntEnum/StrEnum.

The docs even explicitly state

IntEnum, StrEnum, and IntFlag

These three enum types are designed to be drop-in replacements for existing integer- and string-based values

So the purpose of these classes is, as @ambv says to be used exactly this way. I don’t think the examples @Jelle gave really satisfy the idea of a “drop-in replacement” for a regular integer value, because as @Eneg points out, they fail the duck test.

10 Likes