BehaviorEnum: an Enum subclass that bundles a value with a callable - stdlib candidate?

Ideas
,
21

The following works well for me:

from typing import Literal

Method = Literal["post", "put", "get", "delete"]

_do : dict[Method, callable] = {
  "post": do_post,
  "put": do_put,
  "get": do_get,
  "delete": do_delete,
}

def f(method: Method) -> ...:
  _do[method]()

You get:

  • type safety, because my type checker (mypy) can tell when I call f with the wrong method.
  • autocompletion, because my IDE (VS code) can autocomplete in this scenario
  • no need to import anything in order to call f
  • sensible run-time errors too

Thereā€™s another pattern, relevant when you have multiple dispatch sites, which need different behaviours, and allows you to add a new option whilst only editing one place:

### your_lib/operation.py

from dataclasses import dataclass

@dataclass
class Operation:
  func: Callable
  def __call__(self, event): self.func(event)

CREATE_OPERATION = Operation(validate_create)
UPDATE_OPERATION = Operation(validate_update)

## foo.py
from your_lib import operation

event = {"operation": operation.CREATE_OPERATION}

# deserialisation
def event_from_json(json: dict):
  event = {"operation": getattr(operation, json["operation"]}

The only place where I see an enum winning you anything is for the sake of type-hinting deserialisation. But there youā€™re then heavily leaning on the magic created by libraries such as mypy and fastapi, and that magic has just as much potential to hurt you as ā€˜justā€™ having all the names listed in two places. (Once in the definition of the Literal, and once in the lookupdict or whatever your equivalent of your_lib/operation.py is).

2 Likes
22

Iā€™m of the opinion that since Ethan could do this with a simple subclass, not even making a enum type, and then you quickly followed up with a a solution that is mypy friendly, that this should go into the stdlib.

It looks very clean and fits with the paradigm of all the existing special enums in stdlib.

1 Like
23

If you werenā€™t aware, this is valid Python right now:

from enum import Enum

class TaskStatus(Enum):
    NEW         = "new",         lambda: print("Starting task...")
    IN_PROGRESS = "in_progress", lambda: print("Already running.")
    COMPLETED   = "completed",   lambda: print("Nothing to do.")

    def __init__(self, display_name, func):
        self.display_name = display_name
        self.func = func

    def do(self):
        return self.func()


TaskStatus.NEW.display_name     # "new"
TaskStatus.NEW.do()             # Starting task...
2 Likes
24

Iā€™m aware thatā€™s valid syntax - I actually started there. The reason I pulled it into a base class was so the pattern could be used more generally rather than redefining __init__ every time you need this kind of enum in a different part of the codebase.

25

The error message was a symptom, not the problem I was trying to solve - I should have made that clearer in my earlier reply. The broader context was that the rest of the codebase used enums with match/case for this kind of pattern - this one place was an aberration, and I think it happened because a plain enum offered no real advantage over string literals here so the author never bothered.

This is what the handler looks like with BehaviorEnum:

python

class Operation(BehaviorEnum):
    CREATE = "Create", create_op
    UPDATE = "Update", update_op
    READ   = "Read",   read_op
    LIST   = "List",   list_op

def operation_handler(event: dict):
    try:
        operation = Operation(event.get("operation", ""))
        try:
            return operation.do(event)
        except ValidationException as ve:
            log.error(f"{operation.value} operation failed due to validation: {ve}")
            raise
        except Exception as ex:
            log.error(f"{operation.value} operation failed due to unknown error: {ex}")
            raise
    except ValueError:
        log.error("Invalid operation.")

Adding a new operation means one line in the enum - the handler never changes. And since the operation is resolved before the inner try block, the wrong error message in the log becomes much harder to reproduce. You canā€™t define a member without its behavior, so the pattern stays consistent without relying on discipline. Thatā€™s what I was trying to make the enum worth reaching for.

26

Thatā€™s a feature of any dispatch table though.

I donā€™t think your original code is the correct point of comparison for this feature. More appropriate would be code like what @peterc showed above using a string literal, or similar enum+dict code:

class Operation(enum.Enum):
    create = enum.auto()
    delete = enum.auto()

_HANDLERS: dict[Operation, typing.Callable[[InputType], ResultType]] = {
    Operation.create: _create_func,
    Operation.delete: _delete_func,
}

def handle_input(x: InputType) -> ResultType:
    op: Operation = _detect(x)
    return _HANDLERS[op](x)

i.e., Compare it against idiomatic code which uses enums mapped to callables. Is it better?

I agree that the requirement to keep the dict and the enum aligned is a place to look.
Personally, Iā€™d find the following unit test perfectly adequate:

def test_all_operations_define_handlers():
    assert set(Operation) <= _HANDLERS.keys()

If a new enum type is added, I would strongly prefer that the values just be functions. The idea of it being a tuple of a string and a function (as you have shown) is odd. Enum members already have names.
Iā€™m still not really convinced, but if this idea does go ahead, keeping it clear that it is a name->callable mapping will make it more usable.

27

I actually covered this in post 18 - Ethan suggested the @member approach where the values are just functions and the names are the keys, which I agreed was a cleaner design and addresses the tuple oddness entirely.

On the unit test - itā€™s a good idea, but that validation should ideally be baked into BehaviorEnum itself so that every implementation doesnā€™t have to write and maintain it separately. Thatā€™s part of what a shared base class gives you - the guarantee comes with the pattern rather than requiring each team to remember to test for it.

On the comparison with Peterā€™s enum + dict - thatā€™s a fair point and a better baseline than the string literal code I showed earlier. The difference is still the same one though: with the enum + dict you have two structures to keep in sync even if the unit test catches drift. BehaviorEnum collapses them into one so the question of sync never comes up.

28

Iā€™m not sure it makes sense to combine the enum aspect with a dispatch table. Itā€™s convenient, but what happens if you later need a second operation with the same values? Youā€™d have to either abandon the class, or make a second duplicate enum, keep them in sync or have a mapping from one to the other. Both seem problematic.

What might work better is to just have a DispatchTable class, which takes the enum and functions, validates that all values have an associated function, and could be called to dispatch to them. Implementing it either as a class with methods matching the names, or just an object that searches globals() seems like good solutions.