Python 3.10 Match —A New Way to Find Patterns
Python 3.10 introduces the new match keyword which brings, “structural pattern matching” to python. This acts like a switch-case (C++) or match (Rust) statement. This is a really fun feature and today I want to walk through how it works, what you should use it for and review alternative solutions when you can’t use new and shiny features like match .
How it works
match is a fairly straight forward feature to use but has a lot of tools that can be leveraged for specific use cases. The following list is taken straight from the PEP describing the feature, but is one of the best overviews of each aspect of the match feature I have come across.
- A literal pattern is useful to filter constant values in a structure. It looks like a Python literal (including some values like True, False and None). It only matches objects equal to the literal, and never binds.
- A capture pattern looks like x and is equivalent to an identical assignment target: it always matches and binds the variable with the given (simple) name.
- The wildcard pattern is a single underscore: _. It always matches, but does not capture any variable (which prevents interference with other uses for _ and allows for some optimizations).
- A constant value pattern works like the literal but for certain named constants. Note that it must be a qualified (dotted) name, given the possible ambiguity with a capture pattern. It looks like Color.RED and only matches values equal to the corresponding value. It never binds.
- A sequence pattern looks like [a, *rest, b] and is similar to a list unpacking. An important difference is that the elements nested within it can be any kind of patterns, not just names or sequences. It matches only sequences of appropriate length, as long as all the sub-patterns also match. It makes all the bindings of its sub-patterns.
- A mapping pattern looks like {“user”: u, “emails”: [*es]}. It matches mappings with at least the set of provided keys, and if all the sub-patterns match their corresponding values. It binds whatever the sub-patterns bind while matching with the values corresponding to the keys. Adding **rest at the end of the pattern to capture extra items is allowed.
- A class pattern is similar to the above but matches attributes instead of keys. It looks like datetime.date(year=y, day=d). It matches instances of the given type, having at least the specified attributes, as long as the attributes match with the corresponding sub-patterns. It binds whatever the sub-patterns bind when matching with the values of the given attributes. An optional protocol also allows matching positional arguments.
- An OR pattern looks like [*x] | {“elems”: [*x]}. It matches if any of its sub-patterns match. It uses the binding for the leftmost pattern that matched.
- A walrus pattern looks like d := datetime(year=2020, month=m). It matches only if its sub-pattern also matches. It binds whatever the sub-pattern match does, and also binds the named variable to the entire object.
Examples
Here is a general example list of some of the main pattern matching features.
Matching With Enums
Its also possible to match against Enum objects.
Matching Custom Classes with __match_args__
Another interesting aspect of match is the __match_args__ dunder function. This allows you to find define what attributes on a class instance get used in the case expression of a match statement.
This is an interesting feature that I enjoy the syntax and usability of. While some may disagree with its value and place in the language, I intend on using this moving forward for pattern matching situations where otherwise long if statements could become bulky to read compared to match statements. I see this as especially true for situations where sub-patterns, embedded list elements and many conditions are required to check possibility. But we shall see!
