PEP 318

[Ville Vainio]

>>>>> "Andrew" == Andrew Bennetts <andrew-pythonlist at puzzling.org> writes:

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

I know, the decorator syntax just makes these look so much nicer.

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

Yes, the name 'foo' gets clobbered every time, but the decorator
always returns the *dispatcher* that is capable of dispatching the
call to the correct definition of 'foo'. The dispatcher preserves the
references to the callables, so they don't get decreffed out of
existence.

The dispatcher obviously needs a reference to a module global dict
object of some sort, with some magical name like
'__mm_dispatcher_registry'.

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

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

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

It's not. I'm still thinking of multimethods mostly as plain functions
with dynamic dispatching on arg types, not actual methods. To get the
functionality in methods, you just need to call the mm function
explicitly with an unique name inside the method.

I'm not sure whether methods could be dispatched more automatically,
someone might have some ideas?

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

Well, it's just that __mul__ absolutely needs to be a method in order
to be called on seeing an * operator. 'foo' can be taken out of the
class.

-- 
Ville Vainio   http://tinyurl.com/2prnb