
Okay, Jelle and Eric have convinced me. On Wed, Jan 19, 2022 at 11:10 AM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
Spoiler alert: I agree with Eric.
There are two different things you may want to express with a statement like `assert False`:
(1) This code is believed to be unreachable, but I can't convince the type checker that it is. This can be spelled with `assert False`. (2) This code is unreachable, and I want the type checker to tell me if it's not. This can be spelled with the `NoReturn` hack.
Making `assert False` mean (2) in match statements would be inconsistent and would leave no way to express (1).
I'm also not a fan of adding a flag for changing this behavior. Flags are usually for increasing or decreasing the strictness of the type checker, and users will generally want to work towards turning a flag on globally. But with this behavior, you'd want some match statements to enforce exhaustiveness and not others, maybe even in the same file.
I'm also supportive of adding something like `typing.assert_never(x: NoReturn)`. I'm happy to work on implementing this at runtime. It's starting to look like enough new typing functions to write a PEP :).
El mié, 19 ene 2022 a las 8:39, Henry F. Schreiner (<henryfs@princeton.edu>) escribió:
I’d like to gather some opinions or suggestions on exhaustiveness checking on match statements, stemming from https://github.com/python/mypy/pull/10191 (though most future discussion should happen on https://github.com/python/mypy/issues/12010). I’m especially interested in any experience from working with this already, such as in pyright.
# case _: assert False would trigger a type check error if reachable.
This would allow users to mark match statements as exhaustive. This would require assert False to be treated specially by type checkers in a “match all” case statement, but it’s inline with a common usage of assert false at the end of an if chain today, and wouldn’t introduce new constructs.
# --exhaustive-match flag for checkers like mypy
This would be a new “strict' flag added to mypy “strict” that would force match statements to be statically exhaustive - this is not (and maybe could not) be enforced at runtime by Python, but could for a static type checker, and would force case _: pass to be added if fallthrough was expected - to make it explicit, and avoid forgetting to add case _: assert False. At some some codebases would likely benefit from this flag. I assume this could be done by other checkers too. It would be a normal mypy strictness flag, so could be enabled/disabled per module, etc.
# Current workaround
The current workaround for this is to have a function assert_never that takes a NoReturn - NoReturn happens to be (the only) way to spell an empty Union (at least in mypy?). This also works with type narrowing in if statements, so is usable before requiring 3.10+. Until one or both of the above are implemented, it’s the only way to check pattern matching for exhaustiveness, too. Personally, I’d like a slightly nicer way to write this as well, with assert_unreabable or something, or at least a Nothing/EmptyUnion spelling for NoReturn.
I think the current leaning is to implement the first two, and do nothing on the third. Thoughts? Especially on the exhaustive-match flag.
- Henry _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>