Exhaustive checks with assert_never when using match on a 2-tuple fails
#16650
Comments
|
Yes, it looks related. My issue just adds another nuance. |
|
I just ran into this as well (in this library we have homemade res: Result[tuple[A, B], MyException] = ...
match res:
case Ok((a, b)):
...
return Ok(...)
case Err(exc):
return Err(exc)
case _ as unreachable:
assert_never(unreachable)
# ^^^^^^^^^Mypy: Argument 1 to "assert_never" has incompatible type "Ok[tuple[A, B]]"; expected "Never" [arg-type] |
|
Another variant on this shows up when differentiating 2-tuples via explicit string literals : # event is declared as a union of 2-tuples, with literal strings in the first field
match event:
case ("download_progress", update):
self._report_progress(update)
case ("finalize_download", _):
self._finalize_download()
case ("finished", _):
pass
case _:
assert_never(event) # Fails, reporting the full union typeSwitching to matching on In my case, since I control the event definitions, I'm going to switch from using 2-tuples to a dedicated event class which MyPy can both exhaustiveness check and correctly downcast. Since my string literal variation type checks in pyright, but fails in mypy, this issue is presumably due to the tuple-expansion (or lack thereof) mentioned in #16722 (comment) This means that the OP's variation won't typecheck in pyright either (since it requires subtype expansion on both tuple elements) |
Bug Report
I learned about
assert_never, with which checks for exhaustiveness can be performed. I wanted to use it in a match statement where I want to cover all 4 possible scenarios of atuple[int|None, int|None]. Unfortunately, when adding the catch-allcasearm that containstyping.assert_never, I get a typing error indicating a non-exhaustive check above.The error persists in a couple of variations. In particular, it persists when using 1-tuple. However, when matching on one value directly, using
assert_neverworks as intended.To Reproduce
https://gist.github.com/mypy-play/1df3d1b4c9e82226df17094a9f9c6af5
https://mypy-play.net/?mypy=latest&python=3.12&gist=1df3d1b4c9e82226df17094a9f9c6af5
Expected Behavior
All examples in the provided Gist should pass the type checks.
Actual Behavior
Mypy rejects the first three functions of the Gist. In particular, it's output reads:
Your Environment
Since I am using the Gist, I hope my particular environment doesn't matter much.
The text was updated successfully, but these errors were encountered: