I'm genuinely interested (not being snarky, honest) - could you explain why you think that expression has anything to do with multimethods? Like I said previously, I'm new to Python and I'm curious what that expression actually means.

> could you explain why you think that expression has anything to do with multimethods?

You can override the behavior of a function based on the types involved. For instance ``coerce(a, b)`` calls ``a.__coerce__(b)``. By overriding ``__coerce__`` for one type you can customize this.

Do you then have to have conditional code in a.__coerce__(b) to check the type of b and do the appropriate thing?

Basically yes. Although there are ways around it: http://www.artima.com/weblogs/viewpost.jsp?thread=101605

Thanks - that looks quite neat.

It seems to me there is a big difference between having a language that is truly based on multimethods and one where it is possible to implement multimethods fairly easily - from what I can see Python looks more like the latter.

That's called "Operator overloading" In this case the operator happens to look like a function, but it's not really any different than a + b -> a.__add__(b)

That's not just simple operator overloading. What mitsuhiko refers to is that iter() can iterate over an object not just when you implement __iter__() but also when you implement __getitem__() and __len__(), bool() has similar semantics as do several other functions and operators.

I've always heard them referred to as "Generic Functions", though the Wikipedia article is annoying opaque.

The important quality (in my practical understanding) is that a generic function's specialization is decoupled from the object system -- delegating to `x.__iter__()` doesn't require `x` inheriting a method from a parent; the process `iter(x)` uses to delegate might not even require any type information about `x` at all.