Python

When if/elif Gets Messy: A Practical Guide to Python's match Statement

Structural pattern matching turns tangled if/elif chains into readable, declarative code. Here's when to reach for match — and when a plain dictionary is still the better call.

Anton Jacker

— 2 min read

Every Python developer eventually writes a function that grows a long tail of if/elif/else branches. It works, but it reads like a decision tree stapled together by hand. Since Python 3.10, there's a cleaner tool for a specific class of these problems: the match statement, also known as structural pattern matching. It doesn't replace if, and it isn't the C-style switch that people sometimes expect. It's something more interesting — a way to match the shape of your data and pull values out of it in one step.

The problem match actually solves

Imagine you're processing events that arrive as dictionaries. One event is a click with coordinates, another is a keypress with a key name, another is a resize with width and height. With if statements you end up checking a type field, then digging into the dictionary, then binding variables by hand:

def handle(event):
    if event["type"] == "click":
        x, y = event["x"], event["y"]
        return f"click at {x},{y}"
    elif event["type"] == "key":
        return f"key {event['key']}"
    elif event["type"] == "resize":
        return f"resize to {event['w']}x{event['h']}"
    else:
        return "unknown"

The same logic with match collapses the checking and the unpacking into a single readable block:

def handle(event):
    match event:
        case {"type": "click", "x": x, "y": y}:
            return f"click at {x},{y}"
        case {"type": "key", "key": name}:
            return f"key {name}"
        case {"type": "resize", "w": w, "h": h}:
            return f"resize to {w}x{h}"
        case _:
            return "unknown"

Each case describes what the data must look like, and if it matches, the variables are bound automatically. The wildcard case _ is your else. This is the core idea: you're not comparing one value against another, you're testing structure.

Patterns are more than literals

The real power shows up with class patterns and guards. If you model your domain with dataclasses, you can match on the class and its attributes at once:

match shape:
    case Circle(radius=r) if r > 0:
        area = 3.14159 * r * r
    case Rectangle(width=w, height=h):
        area = w * h
    case _:
        raise ValueError("unsupported shape")

The if r > 0 is a guard — an extra condition that must hold for the case to fire. You can also capture a whole sub-value with as, match sequences with [first, *rest], and combine alternatives with the | operator, as in case 401 | 403 | 404:.

When not to use it

Structural pattern matching is not always the right answer. If you're mapping a handful of constant keys to values, a plain dictionary lookup is shorter and faster. If you have exactly two branches, an if is clearer. Reach for match when you're genuinely destructuring data — nested dictionaries, class hierarchies, variable-length sequences — because that's where the syntax earns its place. Overusing it on simple equality checks just adds ceremony.

One subtle trap worth remembering: bare names in a case pattern capture rather than compare. Writing case status: binds anything to status; it does not check against a variable named status. To compare against a constant, use a dotted name like case HTTPStatus.OK: or a literal.

A companion read in German

Pattern matching is one of those features that clicks faster when you see it explained from more than one angle. If you or a colleague prefer a German-language walkthrough, our sister blog Meine Codereise has a thorough introduction that covers the same ground with its own examples: Structural Pattern Matching in Python: match und case verstehen. It's a good second pass if a concept here didn't fully land, and it goes into the mapping and sequence patterns in careful detail.

Structural pattern matching won't transform every function you write, but for parsers, event handlers, and anything that inspects the shape of incoming data, it turns brittle branching into code that states its intent. Try converting one messy if/elif chain in your own project and see whether the result reads better. Usually, it does.

Read more