Having written one of these[1] a decade ago and inflicting it (with the best of intentions) upon production code in anger, I can tell you this often leads to completely unmaintainable code. It is impossible to predict the effect of changing a method, tracing a method, debugging a method (where do I put the breakpoint??).

The code reads beautifully though. Pray you never have to change it.

The reason I say "just use haskell" instead of lisp is bc lisp generics suffer from this same problem.

Btw if anyone has a solution to this "generic/multidispatch maintainability in a dynamically typed language" problem I would love to hear it.

[1]: https://github.com/jjtolton/naga/blob/master/naga/tools.py

Regarding PyPy, I did run some benchmarks recently (I use pytest-benchmark). The advantage over other libraries remains and the magnitude is similar, but when I compare with custom if/isinstance code, that code is optimized a lot more aggressively and it gains a significant edge (let's say ~5x). Now, since I'm into codegen, part of me feels like meeting the challenge and figuring out a way to generate optimal code from a set of signatures, but I think I've spent enough time as it is haha.

See for example https://docs.raku.org/language/functions#Multi-dispatch

In particular, type declarations, as they were first introduced in python, did not have a run-time effect, and they very much have a run-time effect with multi methods.

(Dataclasses are kind of an exception to this rule, but one that feels far less fundamental than multi dispatch would).

One case where I actually rely on multiple dispatch is conversion to more or less structured data. Inspired by Clojure, I have a function `conform(OutputDataType, input_data::SomeType)` and specific implementations depend on both types involved.

Multiple dispatch is also really helpful when two libraries don't quite do the same thing. In python pandas, numpy, and pytorch all have slightly different implementations of x.std() (standard deviation) with slightly different APIs. This means you can't write code that's generic across a numpy array or a pytorch tensor. In Python this could only easily be fixed if library authors coordinate, but with multiple dispatch you can just fix this in your own code.

Example: turning a data structure into a JSON string, solved with multi dispatch: https://github.com/moritz/json/blob/master/lib/JSON/Tiny.pm#...

Another common useful example is constructors. A Date class might have constructors that accept

   Date(Int, Int where 1..12, Int where 1..31) # Y, M, D
   Date(Str where /^\d4-\d2-\d2$/) # YYYY-MM-DD
   Date(DateTime) # extract the date of a DateTime object

One case where I'm finding it extremely useful is that I'm currently using ovld to implement a serialization library (https://github.com/breuleux/serieux, but I haven't documented anything yet). The arguments for deserialization are (declared_type, value, context). With multimethods, I can define

* deserialize(type[int], str, Any) to deserialize a string into an int

* deserialize(type[str], Regexp[r"^\$"], Environment) to deserialize $XYZ as an environment variable lookup but only if the context has the Environment type

* deserialize(type[Any], Path, WorkingDirectory) to deserialize from a file

That's one situation where ovld's performance and codegen capabilities come in handy: the overhead is low enough to remain in the same performance ballpark as Pydantic v2.

If the language is dynamically typed, you can use it for polymorphism.