declaring multimethods [Was: Re: PEP 318]

Joe Mason joe at
Wed Mar 24 18:01:58 CET 2004

In article <mailman.348.1080142389.742.python-list at>, Skip Montanaro wrote:
> Using the proposed PEP 318 semantics, at the time decorator(<function>) is
> called, it will be passed a function object but "__mul__" will not have been
> seen yet.  However, the function object's func_name field should have been
> filled in.  That should give it enough information to build a new function

Oh, good.  That's what I proposed in another post - I guess I didn't
read the PEP closely enough to realize it was already like this.  (It's
a bit weird to have a function with a func_name filled in, but actually
looking up that func_name will return something else or nothing!  But
there would never be a reason to do that when you already have the
function object, so it's a useful asymmetry.)

> type names.  That presents another problem.  Classes, unlike functions,
> don't have name attributes, so mapping the names passed to multimethod() to

Perhaps they should.  (But that's another PEP!)

> It certainly seems doable, but the end result doesn't seem all that pretty.
> I think it would look sort of like:
>     class Matrix [attributes(_name="Matrix")]:

(Why not just "class Matrix: _name = "Matrix" ..."?  "attributes" looks
a little wordy to me.  Just a question of style, but I want to know if
there's a technical reason I'm missing.)

>         def __mul__(self,other) [multimethod("Matrix","Matrix")]:
>             ...
>             return result
>         def __mul__(self,other) [multimethod("Matrix","Vector")]:
>             ...
>             return result
>         def __mul__(self,other) [multimethod("Matrix","Scalar")]:
>             ...
>             return result

I think my preferred way to do this would be just

    class MatrixBase:

    class Matrix(MatrixBase):
        def __mul__(self, other) [multimethod(MatrixBase, MatrixBase)]:
            return result

That gets around the only case that won't work due to visibility,
without forcing all the other cases to use ugly strings. 


More information about the Python-list mailing list