declaring multimethods [Was: Re: PEP 318]
Joe Mason
joe at notcharles.ca
Wed Mar 24 12:01:58 EST 2004
In article <mailman.348.1080142389.742.python-list at python.org>, 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:
pass
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.
Joe
More information about the Python-list
mailing list