Dictionary Dispatch Pattern in Python

Simplify your Python code by replacing all the unnecessary if/else statements and match/case blocks with dynamic dictionary function lookups

Photo by Pawel Czerwinski on Unsplash

Have you ever written a long chain of if/ else statements or a huge match/ case block, with all statements matching against a list of value — and wondered how you could make it more concise and readable?

If so, then the dictionary dispatch pattern might be a tool for you. With dictionary dispatch, we can replace any block of conditionals with a simple lookup into Python’s dict. Here's how it works.

Using Lambda Functions

The whole idea of dictionary dispatch is to run different functions based on the value of a variable instead of using a conditional statement for each value.

Without dictionary dispatch, we would have to use either if/ else statements or a match/ case block like so:

x, y = 5, 3
operation = "add"

if operation == "add":
    print(x + y)
elif operation == "mul":
    print(x * y)

# ---------------

match operation:
    case "add":
        print(x + y)
    case "mul":
        print(x * y)

While this works fine for just a few ifs or case s, it can become verbose and unreadable with a growing number of options.

Instead, we can do the following:

functions = {
    "add": lambda x, y: x + y,
    "mul": lambda x, y: x * y
}

print(functions["add"](5, 3))
# 8
print(functions["mul"](5, 3))
# 15

The simplest way to implement dictionary dispatch is by using lambda functions. In this example, we assign each lambda function to a key in a dictionary. We can then call the function by looking up the key names and optionally passing in parameters.

Using lambdas is suitable when your operations can be expressed with a single line of code. However, in general, using a proper Python function is the way to go.

Using Proper Functions

lambda functions are nice for simple cases, but chances are you will want to dispatch on functions that require more than one line of code. Here’s an example of multiline code:

def add(x, y):
    return x + y

def mul(x, y):
    return x * y

functions = {
    "add": add,
    "mul": mul,
}

print(functions["add"](5, 3))
# 8
print(functions["mul"](5, 3))
# 15

The only difference when using proper functions is that they have to be defined outside the dictionary because Python doesn’t allow for inline function definitions. While this may seem annoying and less readable, it — in my opinion — forces you to write cleaner and more testable code.

Default Result

In case you want to use this pattern to emulate match/ case statements, you should consider using the default value when the dictionary key is not present. Here’s how to do that:

from collections import defaultdict

cases = defaultdict(lambda *args: lambda *a: "Invalid option", {
    "add": add,
    "mul": mul,
})

print(cases["add"](5, 3))
# 8
print(cases["_"](5, 3))
# Invalid option

This snippet leverages defaultdict, whose first argument specifies the "default factory," which is a function that will be called when the key is not found. You will notice that we used two lambda functions here. The first is there to catch any number of arguments passed to it, and the second is there because we need to return a callable.

Passing Parameters

We’ve already seen in all the previous examples that passing arguments to the functions in the dictionary is very straightforward. However, what if you wanted to manipulate the arguments before passing them to a function? Your code may look like this:

def handle_event(e):
    print(f"Handling event in 'handler_event' with {e}")
    return e

def handle_other_event(e):
    print(f"Handling event in 'handle_other_event' with {e}")
    return e

# With lambda:
functions = {
    "event1": lambda arg: handle_event(arg["some-key"]),
    "event2": lambda arg: handle_other_event(arg["some-other-key"]),
}

event = {
    "some-key": "value",
    "some-other-key": "different value",
}

print(functions["event1"](event))
# Handling event in 'handler_event' with value
# value
print(functions["event2"](event))
# Handling event in 'handle_other_event' with different value
# different value

The first option is to use lambda function, which allows us to, for example, look up a specific key in the payload, as shown above.

Another option is to use partial to "freeze" the arguments. That, however, requires you to have the argument/payload before defining the dictionary, as shown below:

event = {
    "some-key": "value",
    "some-other-key": "different value",
}

functions = {
    "event1": partial(handle_event, event["some-key"]),
    "event2": partial(handle_other_event, event["some-other-key"]),
}

print(functions["event1"]())
# Handling event in 'handler_event' with value
# value
print(functions["event2"]())
# Handling event in 'handle_other_event' with different value
# different value

Real World

So far, we have experimented only with hello-world-like code examples. There are many real-world use cases for dictionary dispatch, so let’s take a look at some of them with the following code:

# parse_args.py
import argparse

functions = {
    "add": add,
    "mul": mul,
}

parser = argparse.ArgumentParser()

parser.add_argument(
    "operation",
    choices=["add", "mul"],
    help="operation to perform (add, mul)",
)
parser.add_argument(
    "x",
    type=int,
    help="first number",
)
parser.add_argument(
    "y",
    type=int,
    help="second number",
)

args = parser.parse_args()
answer = functions.get(args.operation,)(args.x, args.y)

print(answer)

The first one parses the CLI arguments. Here we use the built-in argparse module to create a simple CLI application. The code here consists mostly of defining the dictionary and setting up three possible arguments for the CLI.

When this code is invoked from CLI, we will get the following:

python parse_args.py
# usage: parse_args.py [-h] {add,mul} x y
# parse_args.py: error: the following arguments are required: operation, x, y

python parse_args.py add 1 2
# 8

python parse_args.py mul 5 3
# 15

If operation ( add or mul) and two numeric arguments are specified, the arguments get unpacked into args variable. These arguments, along with the args.operation, are then used when invoking the function from dictionary, and the result is assigned to the answer variable.

Another practical example of using dictionary dispatch makes it so your application can react to many different incoming events. For example, a may need to handle multiple pull requests from GitHub. Here’s the code to do that:

event = {
  "action": "opened",
  "pull_request": {
    "url": "https://octocoders.github.io/api/v3/repos/Codertocat/Hello-World/pulls/2",
    "id": 2,
    "state": "open",
    "locked": False,
    "title": "Update the README with new information.",
    "user": {
      "login": "Codertocat",
      "id": 4
    },
    "body": "This is a pretty simple change that we need to pull into master.",
    "sender": {
      "login": "Codertocat",
      "id": 4
    }
  }
}

A GitHub pull request event can specify many different actions, e.g., assigned, edited, labeled, etc. In the code below, we will implement dictionary dispatch for the four most common ones:

def opened(e):
    print(f"Processing with action 'opened': {e}")
    ...

def reopened(e):
    print(f"Processing with action 'reopened': {e}")
    ...

def closed(e):
    print(f"Processing with action 'closed': {e}")
    ...

def synchronize(e):
    print(f"Processing with action 'synchronize': {e}")
    ...

actions = {
    "opened": opened,
    "reopened": reopened,
    "closed": closed,
    "synchronize": synchronize,
}

actions[event["action"]](event)
# Processing with action 'opened': {'action': 'opened', 'pull_request': {...}, "body": "...", ... }

We define an individual function for each action type to handle each case separately. In this example, we directly pass the whole payload to all functions. We could, however, manipulate the event payload before passing it, as we’ve seen in the earlier example.

Visitor Pattern

Finally, while a simple dictionary is usually enough, if you require a more robust solution, you could use the Visitor pattern instead:

class Visitor:
    def visit(self, action, payload):
        method_name = f"visit_{action}"
        m = getattr(self, method_name, None)
        if m is None:
            m = self.default_visit
        return m(payload)

    def default_visit(self, action):
        print("Default action...")


class GithubEvaluator(Visitor):

    def visit_opened(self, payload):
        print(f"Processing with action 'opened': {payload}")

    def visit_reopened(self, payload):
        print(f"Processing with action 'reopened': {payload}")


e = GithubEvaluator()
e.visit("opened", event)
# Processing with action 'opened': {'action': 'opened', 'pull_request': {...}, "body": "...", ... }

This pattern is implemented by first creating a Visitor parent class which has visit function. This function automatically invokes a function with name matching pattern visit_<ACTION>. The child class then implements these individual functions, where each of them acts as one of the "keys" in "the dictionary." To use this pattern/class, we invoke the visit method and let the class decide which function to invoke.

Closing Thoughts

Avoiding conditionals is a sure way to keep things simple. However, that doesn’t mean we should try to shoehorn dictionary dispatch into every piece of code that requires a conditional block.

With that said, there are good use cases for this pattern, such as very long chains of conditional statements. You might also want to use it if you’re stuck using a version of Python that doesn’t support match/ case.

Additionally, the lookup dictionary can be dynamically changed. For example, it is flexible when adding keys or changing the values (functions), which cannot be achieved with normal conditional statements.

Finally, even if you don’t want to use dictionary (table) dispatch, it’s good to be familiar with it because, at some point, you will most likely run into code that uses it. 😉

Python Magic Methods You Might Not Have Heard About

Want to Connect?

This article was originally posted at martinheinz.dev