Why does Python never tell you a match statement is missing a case?

This question separates candidates who have used `match` from candidates who have reasoned about it. The short answer is that exhaustiveness checking requires a closed universe of subjects and patterns whose coverage is decidable, and Python's pattern grammar supplies neither at runtime. ### What would have to be true for the check to exist Languages that check exhaustiveness do so over closed sum types: the compiler knows a value is one of exactly three variants, so it can subtract the covered variants from that set and complain if anything remains. Python has no such construct in the runtime object model. A subject is an object; the set of objects is open. Even when *you* know the subject is one of two enum members, the interpreter does not — the parameter carries no runtime restriction, and the function will happily be called with a string that spells the same thing. ### Every pattern kind resists it **Value patterns** are dotted names, resolved when the case is tried. `case Plan.TRIAL:` reads the attribute at that moment; a module could rebind it between two executions of the same statement, so "which values does this case cover" has no fixed answer before the case runs. **Class patterns** are an `isinstance` test, so they match subclasses too — including subclasses defined in a module imported after this one. A case can start covering values that did not exist when the file was compiled. **Mapping patterns** match a *subset* of keys, so a mapping case is satisfied by an unbounded family of dicts. Subtracting that from "all possible subjects" is not an operation with a finite answer. **Guards** are ordinary Python expressions. Deciding whether a set of guards covers every case is deciding arbitrary Python, which is not a computation the interpreter is going to attempt on your behalf. And the design position reinforces the mechanics: PEP 634 never required exhaustiveness, and a match that matches nothing is a no-op by design, consistent with an `if`/`elif` chain with no `else`. So there is no version of Python where this warning appears — 3.10 through 3.14 all behave identically. An external static checker can prove exhaustiveness for code where the types are declared and closed, but that is a separate tool's analysis of your annotations, not something the interpreter does, and it says nothing about untyped input arriving at runtime. ### What it costs in production, and the discipline that replaces it The canonical failure: a nightly subscription-billing run dispatches on plan codes with a `match`, and the codes it knows are seeded from a plan table that is cached in the worker at startup. Someone adds a new plan; the cache is stale, so a plan code the `match` has never seen reaches the statement. No case matches. No exception. The invoice line for those accounts is never created, and the run reports success. It is caught weeks later, because the totals dashboard only alerts when a run drifts past its 92nd-percentile budget and a few hundred missing lines never came close to that line. Every ingredient of that failure is preventable without an exhaustiveness check: **Make the domain closed in your own code.** Convert the incoming string to an enum member at the boundary, and let *that* conversion be the thing that fails loudly on an unknown value. One well-placed conversion error beats a silent skip in every dispatch site downstream. **End the statement with a wildcard that raises.** `case _: raise ValueError(f"unpriced plan: {plan!r}")`. The `!r` matters — it distinguishes the enum member from a string that spells the same thing, which is usually the actual bug. This is the entire substitute for exhaustiveness checking, and it costs two lines. **Test the closure, not the branches.** Write a test that iterates every member of the enum, calls the function, and asserts no exception. It fails the day someone adds a member without adding a case, which is exactly the moment a compiler would have complained in another language. **Never let the catch-all be silent for a domain you own.** Logging and continuing is the right call for input arriving from outside your system, where new kinds are legitimate. For a set your own code defines, silence just moves the discovery of a bug from a stack trace to a quarterly reconciliation. ### The one-line summary Python tries patterns, it does not analyse them, and dynamic typing means there is no closed set to analyse against. The wildcard-that-raises is the language's answer, and it is the author's responsibility to write it.