decorators and multimethods
 

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=it...net%26rnum%3D1

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

Re: decorators and multimethods
 

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?

Michele Simionato wrote:
> 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=it...net%26rnum%3D1
>
> 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

Re: decorators and multimethods
 

Michele Simionato wrote:
> 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

Re: decorators and multimethods
 

Michele Simionato wrote:

> 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

Re: decorators and multimethods
 

michele.simionato@gmail.com (Michele Simionato) wrote in message news:<4edc17eb.0408062340.71ab270f@posting.google. com>...

<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

Re: decorators and multimethods
 

On 7-aug-04, at 17:42, Michele Simionato wrote:

>
> 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

Re: decorators and multimethods
 

Ronald Oussoren <ronaldoussoren@mac.com> wrote in message news:<mailman.1337.1091896218.5135.python-list@python.org>...
> 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

Re: decorators and multimethods
 

michele.simionato@gmail.com (Michele Simionato) wrote in message news:<4edc17eb.0408062340.71ab270f@posting.google. com>...
>
> 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/p...ly/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.

Re: decorators and multimethods
 

Michele Simionato wrote:
> michele.simionato@gmail.com (Michele Simionato) wrote in message news:<4edc17eb.0408062340.71ab270f@posting.google. com>...
>
> <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