Proposal: LiteralEnum — runtime literals with static exhaustiveness

Typing
4
  1. Do other people feel this pain point as much as me?

YES

  1. Have you found yourself writing duplicate types: a (Literal plus an Enum or just a bare class with attributes)?

YES

  1. Are there alternative designs that could provide a runtime namespace and an exhaustive type hint, without introducing a new core typing construct?

See earlier discussion here: Amend PEP 586 to make `enum` values subtypes of `Literal` - #12 by randolf-scholz

My idea was to amend the typing spec so that — at least for IntEnum and StrEnum — they would be considered subtypes of literal int and str values.

Your proposal may actually be an easier way to get something like this accepted, though I still don’t get why we would need a special type for this rather than supporting it natively on IntEnum and StrEnum. @Jelle gave an example here why this is generally unsafe, but I tested marking the integer / string interface of IntEnum / StrEnum with @final and the mypy-primer results looked good, so I don’t get why we can’t just special case IntEnum and StrEnum rather than inventing a new type for this.

5 Likes