[PEAK] dispatch -- chaining decorators
simon.belak at hruska.si
Fri Dec 9 17:29:56 EST 2005
Ian Bicking wrote:
> I wonder if this decorator library would help:
> 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
> (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:
> 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.
More information about the PEAK