The Python dictionary dispatch pattern

The article talks about string keys, but Python allows many things to be used as keys. For example, instead of chains of `elif` we can look up `True` in a dictionary:

  >>> age = 25
  >>> {
  ...   (age < 18): "Forbidden",
  ...   (age == 18): "OK, you're old enough now",
  ...   (age > 18 and age < 20): "LOL teen emoji amirite?",
  ...   (age >= 20 and age < 40): "Hi",
  ...   (age >= 40): "Welcome",
  ... }[True]
  'Hi'

Of course if you're trying to do a registry-pattern style thing the constraints are different (though there I also think that you end up wanting to base your stuff on classes whose metaclass registers itself based on a string-y class attr or something...)

Though in the end it's super dependent on what kind of code you're trying to write. No rule is absolute, especially in this category of aesthetics.

  mydict[“foobar”]()

  mymod.foobar()

  for name in userfilters:
    im = filtersdict[name](im)

    class Registry:
      constructors = {}

      @classmethod
      def register(cls, other):
        # you can do it by an implicit property or the class name in simple cases. It's better not to use implementation details here, eg you should use an explicit class attribute 
        # you can also verify that the other class holds certain invariants here, so it fails immediately 
        cls.constructors[other.__name__] = other
        # cls.contructors[other.name] = other

      @classmethod
      def from_name(cls, name):
        # error handling code here
        return cls.constructors[name]


    # in something.py
    @Registry.register
    class Something:
      def __init__(self, foo, bar=None):
        self.foo = foo
        self.bar = None

    # In something_test.py
    import something
    import registry

    smth = registry.from_name("Something")

    s = smth('foo', bar=2)

Additionally, the invariant checking can do all sorts of things that you can't do with a base class, eg making sure that overridden properties are still properties, checking that class attributes follow whatever formatting convention you have, etc etc

How is this better than just functions in a module? (import the module as math_exprs, use getattr)

I'm pretty sure it's bad practice but in one project i needed some form of parameterised extensibility (parsing a broad mix of files onto a standard format). So what i did was have other devs subclass an abstract base class I created (with some predefined attributes and methods to fill in) and then generated my execution dictionary based on the attributes of the subclasses of the base class.

  funcs = {}

  def register(key):
    def decorator(func):
      funcs[key] = func
      return func
    return decorator


  @register("some_data_key")
  def do_something_with_some_value(value):
    return value

  # later....
  
   def parse(data):
     return {
       key: func(data.get(key)) for key, func in funcs.items()
     }

  const case = 'case1'

  const result = {
    'case1': 'value1',
    'case2': 'value2',
    'case3': 'value3',
    'case4': 'value4',
  } [case] || 'defaultVal'

"When your OOP support sucks so bad, the people might as well just use maps."

  SUPPORTED_INFERENCE_MODELS = {
    "groundingdino": registry.grounding_dino_base,
    "yolov8": registry.yolov8_bas,
    ...
  }