utility for handler decorator about circuits

[prologic]

Hmm; I'm not quite sure what you mean? What ideas do you have in mind?

Do you mean a decorator to make writing custom decoraotrs that create event handlers a bit easier?

[spaceone]

The problem is that if you want to write a decorator which is applied after @handler one need to

• 1. copy the function metadata of the original function to the decorated function
• 2. copy the code which does the arginspect to know if one have to pass the 'event' to the next function.

[prologic]

Ahh I see; so what are you ideas then?

Turn @handler into a class that can be subclasses?

How else can decorators be extended in this way?

[prologic]

If I'm not mistaken I think you can do something like this:

def mydecorator(*args, **kwargS):
    @handler(...)
    def wrapper(f):
        return f(...)
    return wrapper

I think :)

[spaceone]

Ì think a class is not necessary?!
I would add a function handler_decorator(func) which does the necessary arginspect and use this instead of doing the arginspect in manager.py

[prologic]

e.g: circuits.web.controller.expose

[spaceone]

circuits.web.controller.expose is the best example for the redundant things i want to get rid of:

 if not getattr(f, "event", False):
    return f(self, *args, **kwargs)
else:
    return f(self, event, *args, **kwargs)

[prologic]

Yeah I agree; this is less to do with function parameter inspection and more to do with:

Do we need to send the event object?

I'm not sure how to solve this per se (yet)

[prologic]

Got any ideas around this? I haven't really looked much further into this (yet).

[spaceone]

My description skills weren't that good in 2015.

I explain again with a sample implementation:

class Foo(BaseComponent):
    @handler('foo')
    @my_decorator
    def on_foo(self, event):
       pass

@handler() must always be the outside decorator, as it adds sets attributes at the function which makes them a handler.
on_foo() can in circuits either take event or not.

So my_decorator has to implement the same logic as handler and circuits.core.manager.Manager._dispatcher() - knowing implementation details of circuits (unlikely: and watching on every release if something changed):

from circuits.tools import getargspec
def my_decorator(func):
    @functool.wraps(func)
    def decorated(self, event, *args, **kwargs):
        args = getargspec(func)[0]
        if args and args[0] == "self":
            del args[0]
        with_event = args and args[0] == "event"
        if with_event:
            return func(self, event, *args, **kwargs)
        return func(self, *args, **kwargs)

    return decorated

And my implementation must always take the event argument (OK, probably cannot be prevented).

[spaceone]

If I'm not mistaken I think you can do something like this:

def mydecorator(*args, **kwargS):
    @handler(...)
    def wrapper(f):
        return f(...)
    return wrapper

I think :)

1. I want to chain multiple own decorators
2. I don't want to turn the function into an handler already - because I don't know the other arguments passed to @handler
3. If I do this, I still have to evaluate the event.event flag and call the function differently.

[spaceone]

Ahh I see; so what are you ideas then?

Turn @handler into a class that can be subclasses?

How else can decorators be extended in this way?

No, turning it into a class is optional. Making a subclass is not my need, see the last comment.
But of course creating a class or extra functions is okay.

in PR #311 I changed the handler decorator into a class, providing .call() and .decorate().

This would simplify my example to:

def my_decorator(func):
    handler.decorate(func)
    @functool.wraps(func)
    def decorated(self, event, *args, **kwargs):
        return handler.call(func, self, event, *args, **kwargs)
    return decorated