Fully signature preserving equivalent of functools.wraps about decorator HOT 8 CLOSED

Maybe because I've gone through the trouble of understanding how normal decorators work, I'd rather not figure how the decorator.decorator abstraction works.

Yeah, but take into account that even if I will be able to implement decorator.wraps, it will be a lie: it will look like the standard library utility outside, but it will work according to the decorator.decorator logic inside.

from decorator.

So you would like a decorator.wraps function which is a fully working replacement of functools.wraps?

@decorator.wraps(original)
def wrapper(*args, **kwargs):
    return original(*args, **kwargs)

Perhaps it is possible, but I will have to think about that. I will keep you posted when I will have time to work on that. I actually like the idea, if it can be implemented.

from decorator.

So you would like a decorator.wraps function which is a fully working replacement of functools.wraps?

Yes, this is what I had in mind. We're contemplating using something this for NumPy (but not yet sure it's worth the complexity/run-time of dynamic code generation): http://www.numpy.org/neps/nep-0018-array-function-protocol.html#changes-within-numpy-functions

from decorator.

Well, both scipy and ipython as already using the decorator module as a dependency. In the NEP that you pointed out, there is an array_function_dispatch; if this is the only function of such a type you can just define it without using functools.wraps but with decorator.decorator, no?
You should also measure potential slowdowns due to the decoration, but I guess you have a performance regression suite just for that.

from decorator.

if this is the only function of such a type you can just define it without using functools.wraps but with decorator.decorator, no?

This is probably true, though I have a slight preference for the functools.wraps API. Maybe because I've gone through the trouble of understanding how normal decorators work, I'd rather not figure how the decorator.decorator abstraction works.

You should also measure potential slowdowns due to the decoration, but I guess you have a performance regression suite just for that.

Yes, would definitely be part of the plan before adopting this.

from decorator.

def wraps(func):
    """
    :returns: a decorator for a wrapper function similar to functools.wraps
    """
    return lambda wrapper: decorate(func, lambda f, *a, **k: wrapper(*a, **k))

should act as a replacement of functools.wrapper. However, having thought about that, I will not include this in the decorator library. The point of my library is to make decorator easier, not more perverse. You should marry the decorator library and write your array_function_dispatch somewhat like this, with two levels of nesting less:

@decorator.decorator
def array_function_dispatch(func, dispatcher=None, *args, **kwargs):
    """Wrap a function for dispatch with the __array_function__ protocol."""
    relevant_arguments = dispatcher(*args, **kwargs)
    success, value = try_array_function_override(
        new_func, relevant_arguments, args, kwargs)
    if success:
        return value
    return func(*args, **kwargs)

from decorator.

You should marry the decorator library and write your array_function_dispatch somewhat like this, with two levels of nesting less:

How would I get access to new_func in this example? (I agree that this is a somewhat unusual use-case.)

from decorator.

Ops, I missed that. In your original code you are calling new_func from inside its own definition?

        def new_func(*args, **kwargs):
            relevant_arguments = dispatcher(*args, **kwargs)
            success, value = try_array_function_override(
                new_func, relevant_arguments, args, kwargs)
            if success:
                return value
            return func(*args, **kwargs)

Then I should read the NEP and understand the context, first ;-) But now I am leaving for work, I will come back to this later on.

from decorator.