Python 3.10 beta 1 dropped on May 3rd, and while there are several nice improvements in this release, one feature dominates the conversation: structural pattern matching. Implemented through PEP 634, 635, and 636, this is arguably the most significant syntax addition to Python since async/await landed in 3.5. Having spent the past week experimenting with it, I have thoughts — mostly positive, with some caveats.
More Than a Switch Statement#
The immediate reaction from many developers has been “Python finally gets a switch statement.” That’s technically true but dramatically undersells what structural pattern matching actually is. If you’ve used pattern matching in Rust, Scala, or Elixir, you’ll recognize the power here. If you haven’t, prepare to rethink how you handle complex conditional logic.
The basic syntax uses match and case:
def handle_command(command):
match command:
case "quit":
return shutdown()
case "status":
return get_status()
case other:
return f"Unknown command: {other}"That looks like a switch statement, sure. But the real power emerges when you start matching against structures:
def process_event(event):
match event:
case {"type": "click", "position": (x, y)}:
handle_click(x, y)
case {"type": "keypress", "key": str(k)} if len(k) == 1:
handle_keypress(k)
case {"type": "resize", "dimensions": (w, h)} if w > 0 and h > 0:
handle_resize(w, h)You’re destructuring dictionaries, binding variables, applying type checks, and adding guard clauses — all in a readable, declarative syntax. This is a fundamental improvement over chains of if/elif with nested dictionary access and type checking.
Where This Actually Shines#
I’ve been refactoring some of my own code to use pattern matching, and the areas where it excels are clear.
API response handling is the obvious one. If you work with REST APIs or message queues, you’re constantly writing code that inspects the shape of incoming data and branches accordingly. Pattern matching makes this dramatically cleaner:
match response.json():
case {"status": "ok", "data": {"users": [first, *rest]}}:
process_user(first)
queue_remaining(rest)
case {"status": "error", "code": 429, "retry_after": seconds}:
schedule_retry(seconds)
case {"status": "error", "code": code, "message": msg}:
log_error(code, msg)AST processing and compiler work benefits enormously. If you’re writing linters, code transformers, or DSL interpreters — all increasingly common in the Python ecosystem — pattern matching is a natural fit.
State machine implementations become more readable too. Instead of sprawling if/elif chains checking current state and input combinations, you match on tuples of (state, event) and the code reads almost like a state transition table.
The Controversy: Is This Pythonic?#
Not everyone is happy. The discussion around PEPs 634-636 was one of the most heated in recent Python governance history. Critics argue that pattern matching adds significant complexity to the language for a feature that experienced Python developers have been working without for 30 years. The match and case keywords are “soft keywords” — they’re only treated as keywords in the context of a match statement, which means existing code using match or case as variable names won’t break, but it does add cognitive overhead to the parser and to developers reading code.
There’s also the learning curve concern. Python’s strength has always been its readability and gentle learning curve. Structural pattern matching, especially with guard clauses, class patterns, and nested destructuring, introduces concepts that are genuinely advanced. A newcomer encountering case Point(x, y) if x > 0: for the first time has a lot to unpack.
I understand these concerns, but I think they’re outweighed by the benefits. Python has grown beyond its scripting roots. It’s now a dominant language in data science, web backends, DevOps tooling, and increasingly in systems programming. The developers using Python today need these kinds of expressive constructs, and the alternative — convoluted if/elif chains with isinstance checks — isn’t exactly a paragon of readability either.
Performance Considerations#
One question I haven’t seen adequately addressed yet is performance. The beta implementation compiles match statements to a sequence of checks, similar to how the equivalent if/elif chain would work. There’s no jump table optimization for simple value matching, at least not yet.
For most use cases, this doesn’t matter — you’re typically matching against a handful of cases, not thousands. But it’s worth noting that pattern matching is primarily a readability and expressiveness feature, not a performance one. If you’re expecting C-style switch statement performance with computed gotos, you’ll be disappointed.
The CPython team may optimize this in future releases, but for now, treat it as syntactic improvement rather than a performance tool.
My Take#
After a week of experimentation, I’m genuinely excited about structural pattern matching in Python. It’s the kind of feature that, once you start using it, makes you wonder how you wrote certain kinds of code without it. The API response handling pattern alone will save me dozens of lines of awkward nested dictionary access in several active projects.
That said, I’d caution against the temptation to use it everywhere. Not every conditional needs pattern matching. A simple if x > 10 doesn’t become better as match x: case n if n > 10:. Use it where you’re genuinely matching against structure — destructuring data, handling multiple message types, implementing state machines. That’s where it shines.
Python 3.10 final is expected in October. Between now and then, the beta period is exactly the right time to experiment and provide feedback. If you maintain a library, start testing against 3.10 now — not for pattern matching compatibility, but because several other changes around type hints, error messages, and deprecations might affect your code.
The language keeps evolving, and this time, it’s evolving in a direction I’m genuinely enthusiastic about.