How does structural pattern matching (`match`/`case`, introduced in Python 3.10) differ from a chain of `if`/`elif` statements?

Difficulty: 5/10

Control Flow & Loops, Structural Pattern Matching, Destructuring and Guards

match/case: destructuring pattern matching, not a switch

A chain of if/elif evaluates boolean expressions one after another. match/case compares the structure of a subject against patterns: it can test the type, the shape (length of a sequence, keys of a mapping, attributes of an object) and bind variables to the parts in a single step, with an optional if guard for extra conditions. It is closer to destructuring in functional languages than to a C switch; Python's match is not limited to constants.

javascript

Capabilities beyond if/elif: sequence patterns with star captures, mapping patterns (extra keys are ignored by default, **rest captures them), class patterns that check isinstance and then attributes, or-patterns with |, 'as' binding, and guards. Sequence patterns deliberately do not match str, bytes or bytearray, so 'hello' will not be treated as a list of characters. Class patterns with positional sub-patterns rely on match_args, which dataclasses and namedtuples generate automatically; for ordinary classes you define it yourself.

The mistakes I flag most: (1) a bare name in a pattern is a capture, not a comparison, so case RED: matches anything and rebinds RED (the compiler raises a SyntaxError if later cases become unreachable); compare to constants using dotted names like Color.RED or literals. (2) Thinking match is a faster switch - it is evaluated top to bottom like if/elif and is not generally compiled to a jump table, so choose it for readability, not speed. (3) Using it on 3.9 or earlier: it is a syntax error there, and match and case are soft keywords so existing variables with those names still work.

Trade-offs: match shines for parsing ASTs, commands, JSON-like events and protocol messages, where the shape determines the logic; a dict dispatch table or polymorphism is still better for simple value-to-action mapping or when behavior belongs on the class; plain if/elif is clearer for unrelated boolean conditions. If you support multiple Python versions, match locks you to 3.10+. Type checkers can verify exhaustiveness for enums and unions, typically with assert_never in a final case.

Scenario Questions

0-2 years experience

1Write a match statement that returns 'weekend', 'weekday' or 'invalid' for a day-name string.
2What does case _: do, and what happens if no case matches and there is no wildcard?

2-5 years experience

1You receive commands as lists such as ['move', 3, 4] or ['quit']. Show how sequence patterns with captures replace an if/elif chain of len() checks.
2A teammate's case RED: matches everything and silently rebinds RED. What went wrong, and how do you match against constants or enum members correctly?

5-8 years experience

1You handle nested JSON-like event dictionaries. How do mapping patterns, guards and **rest work, and what are their limitations compared with explicit validation?
2Design a class so it can be used in class patterns like case Point(x=0, y=0) and positional patterns. What role does __match_args__ play, and what do dataclasses give you for free?

8+ years experience

1Your library must support Python 3.8 through 3.12. Do you adopt match? Discuss compatibility, tooling, exhaustiveness checking with assert_never, and when dict dispatch or polymorphism is better.
2Is match compiled to a jump table? Discuss evaluation order, the side effects of patterns and guards, and pitfalls when a pattern triggers properties or custom __eq__ methods.

Follow-up Questions

Why does `case RED:` match every value, and how do you compare against a constant instead?
How do you make a custom class work with positional class patterns such as `case Point(0, 0)`?

Sharethis question

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.