[PEAK] dispatch -- chaining decorators

[Simon Belak]

Ian Bicking wrote:
 >
 > I wonder if this decorator library would help:
 > http://www.phyast.pitt.edu/~micheles/python/documentation.html
 >
 > It's supposed to maintain function signatures.
 >

decorator is a bit limiting as it is my understanding that it can only 
be applied to functions with signature _(f, *args, **kw).

Phillip J. Eby wrote:

 > At 08:31 PM 12/9/2005 +0100, Simon Belak wrote:
 >
 >
 > A trivial fix would be for __entangle to check 'func' for a
 >  next_method argument, and to define a variant def 
__func(next_method, > *args, ...) in that case.
 >

Great, it works a treat.
Will next_method always be the first argument or is it better to check 
throughout?

 > (Meanwhile, note that if you have a bunch of
 > around("something(some_param)") cases, you're likely going to end up
 > with method ambiguities.)
 >

I know. is_pickle() is just a shorthand for checking if the argument is 
an instance of one of a bunch of types:

@is_pickle.when([file, StringIO])
def is_pickle(obj):
     return True


 > I can't know without understanding your framework if that's the case. 
  But if generic functions aren't reducing the *number* of operations 
you have, then I would be concerned.  Note that peak.security.rules uses 
two generic functions and three classes in order to implement a fairly 
sophisticated ACL framework.  If your framework isn't dissolving into a 
surprisingly small number of simple generic functions, I'd say you're 
right to worry, because it means you haven't assimilated them yet, and 
therefore might well be "overusing" them.  But if they're *dissolving* 
the framework, then you have assimilated them (or they've assimilated 
you), and everything's fine.
 >

You have put my mind to rest.
Comparing to the last branch not using generic functions extensively, 
the size has gone down 23% and number of code lines for ~10% while 
introducing additional functionality. So I guess I'm doing fine.


-Simon