Pattern matching

Pattern matching is one of those features that, once you’ve seen it, you’ll need every time and everywhere. Sadly, only few languages have this feature.

What is it?

Pattern matching is a bit like a case statement, but more powerful. You specify a pattern to match and the language executes the branch that matches.

Here’s an example in Erlang, shamelessly copied from Erlang By Example:

postman() ->
    receive
        {send, {Fr, To, _Content} = Pkg} ->
            io:format("~s sending something to ~s ~n", [Fr, To]),
            self() ! {recv, Pkg},
            postman();
        {recv, {To, Fr, Content} = _Pkg} ->
            io:format("~s got a ~s from ~s~n", [Fr, Content, To]),
            postman();
        stop ->
            io:format("Shutting down postman ...~n")
    end.

Here, each pattern is specified as a tuple {verb, {param1, param2} = Pkg}. When the pattern receives a tuple containing the word send, and three more items, it’ll execute the first branch. When it receives the word recv and three more items it’ll execute the second branch. And when the word stop is received, it’ll execute the third branch. Any other receive’s will result in none of the branches executed.

I’m sure you can see how powerful that is: any time you need to find commands with parameters, or must react to incoming data, or must switch on complicated scenarios, this will make the program readable and easy to understand.

In python, you’d have to use either a long if statement or a dictionary switch:

def a(**kwargs):
    pass

def b(**kwargs):
    pass

def default(**kwargs):
    pass

def match_similar(command, **kwargs):
    matcher = {
        'send': a,
        'recv': b,
    }
    
    if command == 'stop':
        return None
    fun = matcher.get(command, default)
    return fun(kwargs)

Note that this is not exactly the same, since the Erlang version actually does the stopping inside the statement. Also, in the Erlang version, the parameters are checked before the a and b subfunctions are called, which in Python we’d have to do inside of the functions.

So, not as cool.

How can I use that cool technique?

Sadly, only a handful of languages have pattern matching mechanisms, among these mostly functional languages like Haskell, Erlang, Ocaml or Elixir.

And, crucially, Python. Well, Python 3.10, which is scheduled for release in October 2021. And it’s fantastic, both from a syntax perspective as well as from matching power.

Here’s a quick example from the tutorial. Without explaining anything, I’m sure you can immediately see what’s happening:

def http_error(status):
    match status:
        case 400:
            return "Bad request"
        case 401 | 403:
            return "Not allowed"
        case 404:
            return "Not found"
        case 418:
            return "I'm a teapot"
        case _:
            return "Something's wrong with the Internet"

Note the newly-introduced match keyword, which isn’t syntax-highlighted here because it’s not actually valid Python yet. This is fantastic: concise, to the point, easy to read and understand and also easy to write. I didn’t have to explain anything about it and you immediately understood it.

Any time a program has to deal with even a slight ambiguousness, pattern matching will make the program much simpler: parsing JSON, accepting commands, reading configuration, even teasing out different sections of data, any many more.

I love it.

The example from above would now look something like this:

def postman():

    while received := receive():
        match received:
            case ("send", fr, to, *content):
                print(f"{fr} sending something to {to}")
                # TODO: do sending
            case ("recv", to, fr, content):
                print(f"{fr} got {content} from {fr}")
                # TODO: do receiving
            case ("stop", ):
                print("stopping postman")
                return

Of course, there’s much more to behold here, and you should definitely read the tutorial. I’m going to link that a few more times, just to be sure you’ll actually do it!

Pattern matching and types

Matching on values is great and all, but it becomes really amazing when you add types. Because you can match on types. Here’s another example from the tutorial:

class Point:
    x: int
    y: int

def where_is(point):
    match point:
        case int:
            print(f"scalar at X={point}")
        case Point(x=0, y=0):               # line 9
            print("Origin")
        case Point(x=0, y=y):               # line 11
            print(f"Y={y}")
        case Point(x=x, y=0):               # line 13
            print(f"X={x}")
        case Point():
            print("Somewhere else")
        case _:
            print("Not a point")

Not only is this matching on a type, it’s also matching on the parameters of that type. Please note that the matching syntax does not call the constructor, instead it matches on the attributes of the given value.

Behind the scenes, line 9 would probably expand to something like if isinstance(point, Point) and hasattr(point, "x") and getattr(point, x) == 0 and hasattr(point, "y") and getattr(point, "y") == 0, with variable binding added in lines 11 and 13.

In a sense, pattern matching and type annotations are opposites, or maybe complements. While type annotations say “this variable must conform to this specific type”, with pattern matching you say “well, if we get this type, better do that”.

Pattern matching and structure

But you can go one step further and match on structure. This is super-useful when you need to parse any kind of data. Here’s some code from my weather warning thingie:

rain_branch = data['hourly'][0].get('rain')
print(datetime.now(), rain_branch)

will_rain = rain_branch is not None

if was_rain and will_rain:
	pass
elif was_rain and not will_rain:
	send(f"rain will stop within the hour")
	was_rain = False
elif not was_rain and will_rain:
	rain_amount = rain_branch.get('1h')
	send(f"rain within the hour: {rain_amount:.2f}")
	was_rain = True
elif not was_rain and not will_rain:
	pass

This code determines whether it will rain and, depending on whether it did rain, sends an appropriate message. This code is… reasonably clear, I’d say. The gnarly bit is the top, where we fetch the appropriate data from the weather API return values.

With pattern matching, you can just write down the structure of the thing you’re interested in, like this:

match (was_rain, data):
    case True, {'hourly': []}:
	    send(f"rain will stop within the hour")
	    was_rain = False
    case False, {'hourly': [{'rain': {'1h': float(rain_amount)}}]}:
	    send(f"rain within the hour: {rain_amount:.2f}")
	    was_rain = True
    case _, _:
        send(f"I got something unexpected: {data}")

DO YOU SEE THIS?
{'hourly': [{'rain': {'1h': float(rain_amount)}}]}
Just put the paths you’re interested in there, slap some variable names in and it’ll give the data to you if it exists. And it’ll even validate that it’s a float for you.

Summary

This is awesome.

Pattern matching is a feature that I’ve missed in Python for a long time, and I’m glad to finally see it appear in 3.10.

 

This post was co-authored by Plantprogrammer