Have you ever written a long chain of if
/else
statements or a huge match
/case
block, with all statements just matching against a list of values, and wondered how could you make it more concise and readable?
If so, then 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 that we run different functions based on the value of a variable, instead of using conditional statement for each of the values.
Without dictionary dispatch, we would have to use either if
/else
statements or 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 if
s or case
s, it can become verbose and unreadable with 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 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 single line of code, however, in general using proper Python function is the way to go...
Using Proper Functions
lambda
functions are nice for simple cases, but chances are that you will want to dispatch on functions that require more than one line of 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
Only difference when using proper functions is that they have to be defined outside of 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, then you should consider using default value for when dictionary key is not present:
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
, who's first argument specifies the "default factory", which is a function that will be called when key is not found. You will notice that we used 2 lambda functions here - 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?
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
First option is to use lambda
function, which allows us to - for example - lookup 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:
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 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:
# 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)
First one being parsing of CLI arguments. Here we use builtin argparse
module to create a simple CLI application. The code here consists mostly of defining the dictionary and setting up 3 possible arguments to 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 2 numeric arguments are specified, then the arguments get unpacked into args
variable. These arguments along with the args.operation
are then used when invoking the function from dictionary, result of which is then assigned to the answer
variable.
Another practical example of using dictionary dispatch is reacting to many different incoming events - for example - from a webhook, such as pull request events from GitHub:
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
}
}
}
GitHub pull request event can specify many different actions, e.g. assigned
, edited
, labeled
, etc. Here we will implement dictionary dispatch for the 4 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, so that we can handle each case separately. In this example we directly pass the whole payload to all of the functions, we could however, manipulate the event payload before passing it, as we've seen in earlier example.
Visitor Pattern
Finally, while simple dictionary is usually enough, if you require a more robust solution you could use 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>
. These individual functions are then implemented by the child class - where each of them is essentially acts as one of the "keys" in "dictionary". To then use this pattern/class we simply invoke visit
method and let the class decide which function to invoke.
Closing Thoughts
Avoiding conditionals is a sure way to keep things simple, that however doesn't mean that we should try to shoehorn dictionary dispatch into every piece of code that requires 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 - for whatever reason - you're stuck using version of Python that doesn't support match
/case
.
Additionally, the lookup dictionary can be dynamically changed, for example by adding keys or changing the values (functions), which is something that cannot be achieved with normal conditional statements.
Finally, even if you don't want to use dictionary (table) dispatch, it's good be familiar with it, because at some point you will most likely run into code that uses it. 😉