Multimethods

[Neel Krishnaswami]

Paul Prescod <paul at prescod.net> wrote:
> Neel Krishnaswami wrote:
> > 
> > ....
> > 
> > So multimethods. In ordinary OO programming, you can think of a method
> > as a set of functions, and the function body that's chosen is based on
> > the runtime type of the first argument.
> 
> You could, but Python exposes so much of the underlying implementation
> that this is not a very intuitive way to think about it. In particular,
> every instance of a class could have a *unique method* frob simply by
> assigning to the frob attribute. 

I don't understand you here. 

The way I understand method dispatch in Python to work is as follows.
If a name lookup that searches a class finds a function, that function
is wrapped in method clothing and returned. Assigning a function to an
instance slot will simply put a function in the slot.

class Foo:
    pass

x = Foo()

Foo.bar = lambda self: "Hello world!"
x.baz = lambda self: "Ni!"

This gives:

>>> x.bar
<method Foo.<lambda> of Foo instance at 80dade0>
>>> x.baz
<function <lambda> at 80db878>

> So it isn't clear to me how you extend this into multimethods. [...] 
> I mean the first step would be to make a form of Python method
> invocation that is type-based even for one argument.

I agree with this. My multimethod module for Python requires passing a
tuple of types (classes or builtin) to the generic function to let it
dispatch correctly. This is very inconvenient.  Multimethods, in all
their glory, will have to wait until after the types-sig figures out
what the type system should look like.


Neel