Open otaj opened 7 months ago
I also just spent 10-minutes fighting this and thought I was going crazy. Single-item enums are typically intended to eventually have more than one item; so exhaustiveness checks on their use are valid and useful (to keep things in sync).
This seems to be fixed in version 1.10. I've just tried the example in mypy-play, and it passes just fine.
Fixed here: https://github.com/python/mypy/pull/16966
Duplicate with: https://github.com/python/mypy/issues/14109
Bug Report
When there is only one member of the enum,
mypy
doesn't perform full exhaustiveness checking and reachesassert_never
statement, although it shouldn't.To Reproduce
mypy-play link
Expected Behavior
mypy
does not complain and reports no errorsActual Behavior
mypy
reaches unreachable code and complainsmain.py:15: error: Argument 1 to "assert_never" has incompatible type "A"; expected "NoReturn" [arg-type]
Your Environment
Playground
Rationale
While having an enum with only one member is definitely a contrived example, it is a valid example nonetheless. This popped up for me while I was implementing a feature partially for just one case of an enum first with the plan of filing up more enum cases later on.
Note that this is specific for enums with one member only, if you have a
Literal
with only one member,mypy
correctly deduces that unreachable code is truly unreachable. If you have an enum with multiple members (and an appropriate match-case block), the unreachable code is also correctly deduced.