PEP 318

[Andrew Bennetts]

On Wed, Mar 24, 2004 at 11:45:05AM +0200, Ville Vainio wrote:
> >>>>> "Andrew" == Andrew Bennetts <andrew-pythonlist at puzzling.org> writes:
> 
>     Andrew> But the decorator syntax doesn't help with this case at
>     Andrew> all.
> 
>     Andrew> You *could* hack up multimethods today, though, by abusing
>     Andrew> metaclasses:
> 
> Hmm? I would have figured that once you are able to associate
> parameter types with a function name and a concrete callable the gets
> called, you can implement multimethods.
> 
> The wrapper would essentially
> 
> 1. Look up the function name N from func_name
> 
> 2. Insert the mapping of parameter types to the callable in the
>    data structure that holds the mappings for multimethod N
> 
> 3. Return the dispatcher object that remembers it's a dispatcher for
>    multimethod N, so, when called, it can search the data structure
>    for its own multimethod for the concrete callable to invoke with
>    the parameters.

Decorators don't add any new capabilities to python, just a more convenient
spelling for existing features.

So, your proposal would work equally well (functionally, anyway, just not
look as nice) like this:

class C:
    def foo(self, other):
        ...
    foo = multimethod(Matrix, Matrix)(foo)

    def foo(self, other):
        ...
    foo = multimethod(Matrix, Vector)(foo)

Which is to say, I don't understand how that can work -- the first
definition of foo gets clobbered.

You *could* have a global registry that's keyed off func_name, as you
suggest, but that doesn't work in general... what if I later have:

class C2:
    def foo(self, other):
        ...
    foo = multimethod(Long, String)(foo)

How is the registry not going to help distinguish between the foo methods
from C, and the foo methods from C2? 

> This would obviously be used for CLOS-style multimethods, i.e. the
> concrete methods would be plain functions. This wouldn't work for
> operator overloading, for example, unless all the dispatcable classes
> did a:
> 
> class C:
>     def __mul__(self, other):
>         return mm_multiply(self,other)

I don't understand why __mul__ is any different to foo here.

> Again, I might be overlooking something, but I haven't yet figured out
> what :).

I might be missing something too, but I don't yet see what :)

-Andrew.