decorators and multimethods

[Michele Simionato]

Decorators can generate endless debate about syntax, but can also
be put to better use

Actually I was waiting for decorators to play a few tricks that were
syntactically too ugly to be even imaginable for Python 2.3.

One trick is to use decorators to implement multimethods. A while ago
Howard Stearns posted here a recipe to implement generic functions
a.k.a multimethods.

I have not studied his recipe, so don't ask me how it works. All I
did was to add an "addmethod" function and save his code in a module
called genericfunctions.

Decorators allowed me to use the following syntax:

# BEGIN generic functions in Python, example
# use code and examples from Howard Stearns

from genericfunctions import Generic_Function, addmethod

foo = Generic_Function()

@addmethod(object, object, object)
def foo(_, x, y, z):
return 'default'

@addmethod(int, int, int)
def foo(call_next, x, y, z):
return 'all ints , ' + call_next(x, y, z)

@addmethod(object, object)
def foo( _, x, y):
return 'just two'

print foo # the multimethod table as a dictionary
print foo(1, 2, 'three') # => default
print foo(1, 2, 3) # => all ints, default
print foo(1, 'two') #> just two
print foo('oops') #=> genericfunctions.NoNextMethod error

# END generic functions in Python, example

Howard Stearns' code is posted here
http://groups.google.it/groups?hl=i....*&selm=40C3BC71.5050206%40charter.net&rnum=1

I just added the following function:

import sys

def addmethod(*types):
"""sys._getframe hack; works when the generic function is defined
in the globals namespace."""
caller_globs = sys._getframe(1).f_globals
def function2generic(f):
generic = caller_globs[f.func_name]
generic[types] = f
return generic
return function2generic

Decorators did all the rest Just to add an use case I haven't
seen before.

Michele Simionato

 

[Howard Stearns]

Hey, that's pretty nice. I'll have to get some coffee and study this. What
do I read about? I can't find anything about @ or 'decorator' in the 2.3
documentation. What should I be looking for?

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

def addmethod(*types):
"""sys._getframe hack; works when the generic function is defined
in the globals namespace."""
caller_globs = sys._getframe(1).f_globals
def function2generic(f):
generic = caller_globs[f.func_name]
generic[types] = f
return generic
return function2generic

Couldn't you use f.func_globals to avoid the getframe hack?

Regards,
Martin

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

foo = Generic_Function()

@addmethod(object, object, object)
def foo(_, x, y, z):
return 'default'

On a second note, I would probably prefer a different notation

foo = Generic_Function()

@foo.overload(object, object, object)
def foo(_, x, y, z):
return 'default'

This, of course, requires changes to Generic_Function, but
they could be as simple as

def overload(self, *types):
def decorator(f):
self[types] = f
return self
return decorator

Regards,
Martin

 

[Michele Simionato]

(e-mail address removed) (Michele Simionato) wrote in message
<snip using decorators as syntactic sugar over Howard Stearns module>

Martin v. Lewis suggested an improvement, which involves adding the
following method to the Generic_Function class:

def addmethod(self, *types):
"My own tiny modification to Stearns code"
return lambda f: self.setdefault(types,f)

The advantage is that methods definitions can go in any scope now and
not only at the top level as in my original hack.
My previous example read:

foo = Generic_Function()

@foo.addmethod(object, object, object)
def _(call_next, x, y, z):
return 'default'

@foo.addmethod(int, int, int)
def _(call_next, x, y, z):
return 'all ints , ' + call_next(x, y, z)

@foo.addmethod(object, object)
def _(call_next, x, y):
return 'just two'

where I use "_" as a poor man anonymous function. I cannot reuse the name
"foo" now, since

@foo.addmethod(...)
def foo(..):
....

is really converted to

def foo(..)
...

foo=foo.addmethod(...)(foo)

and this would correctly raise a "foo function has not attribute addmethod"!
But in some sense this is better, since we avoid any confusion
between the member functions and the generic function (which is implemented
as a dictionary, BTW).

Michele Simionato

 

[Ronald Oussoren]

where I use "_" as a poor man anonymous function. I cannot reuse the
name
"foo" now, since

@foo.addmethod(...)
def foo(..):
....

is really converted to

def foo(..)
...

foo=foo.addmethod(...)(foo)

No it isn't. The decorators are called before the function is added to
a namespace, e.g. it's more like:

def _():
def foo(..):
..
return foo

foo = foo.addmethod(...)(_())

Ronald

 

[Michele Simionato]

decorators are called before the function is added to
a namespace

You are right. I did some experiment with

def dec(f):
print globals()
return f

and it is clear that

@dec
def f():
pass

is NOT the same as

def f():
pass
f=dec(f)

Using the @decorator, f is not in the globals at the decorator call time.
In the version of the PEP I have read (that my have changed) complete
equivalence was claimed, so I assumed (wrongly) this was the cause of
the error I saw. Instead the error came from the second call to the
decorator, not from the first one.

Michele

 

[Phillip J. Eby]

One trick is to use decorators to implement multimethods. A while ago
Howard Stearns posted here a recipe to implement generic functions
a.k.a multimethods.

I have not studied his recipe, so don't ask me how it works. All I
did was to add an "addmethod" function and save his code in a module
called genericfunctions.

Decorators allowed me to use the following syntax:

# BEGIN generic functions in Python, example
# use code and examples from Howard Stearns

from genericfunctions import Generic_Function, addmethod

foo = Generic_Function()

@addmethod(object, object, object)
def foo(_, x, y, z):
return 'default'

@addmethod(int, int, int)
def foo(call_next, x, y, z):
return 'all ints , ' + call_next(x, y, z)

@addmethod(object, object)
def foo( _, x, y):
return 'just two'

FYI, there's another example of this approach available in PyProtocols
CVS; see:

http://www.eby-sarna.com/pipermail/peak/2004-July/001598.html

It uses this syntax:

from protocols.dispatch import when, next_method
[when("True")]
def foo(x,y,z):
return "default"

[when("x in int and y in int and z in int")]
def foo(x,y,z):
return "all ints, "+next_method(x,y,z)

but will work with Python 2.2.2 and up. It also allows arbitrary
expressions to be used to distinguish multimethod cases, not just type
information, but still optimizes them to table lookups. It doesn't
support variadic or default arguments yet, though.

 

[David Fraser]

(e-mail address removed) (Michele Simionato) wrote in message
<snip using decorators as syntactic sugar over Howard Stearns module>

Martin v. Lewis suggested an improvement, which involves adding the
following method to the Generic_Function class:

def addmethod(self, *types):
"My own tiny modification to Stearns code"
return lambda f: self.setdefault(types,f)

The advantage is that methods definitions can go in any scope now and
not only at the top level as in my original hack.
My previous example read:

foo = Generic_Function()

@foo.addmethod(object, object, object)
def _(call_next, x, y, z):
return 'default'

@foo.addmethod(int, int, int)
def _(call_next, x, y, z):
return 'all ints , ' + call_next(x, y, z)

@foo.addmethod(object, object)
def _(call_next, x, y):
return 'just two'

where I use "_" as a poor man anonymous function. I cannot reuse the name
"foo" now, since

@foo.addmethod(...)
def foo(..):
....

is really converted to

def foo(..)
...

foo=foo.addmethod(...)(foo)

and this would correctly raise a "foo function has not attribute addmethod"!
But in some sense this is better, since we avoid any confusion
between the member functions and the generic function (which is implemented
as a dictionary, BTW).

Another benefit is you can give the different variants real names:

@foo.addmethod(object, object):
def add_objects(call_next, x, y):
return 'just two'

so you can call it directly if you want

David