Please use __annotations__ instead of inspect.signature


#1

With 4.x and 5.x it’s not possible to enclose the handler to handle exceptions and a custom and always present response object.

def decorator(func):
    def wrapper(*args, **kwargs):
        try:
            ret = func(*args, **kwargs)
            return success(ret)
        except Exception as exc:
            logger.exception()
            return error(exc)   
     return wrapper

#2

I assume you’d need to use ‘functools.wraps’ right?


#3

Rigth, but inspect inspects the code object wich is a unannotated args and kwargs, i.e. don’t know about any stuff done by wraps. But wraps copy annotations, so this change would be appreciated.


#4

Ditto, I am trying to write a decorator that injects a http.Cookie annotation into a view but cannot get the dependency injector to recognize the added kwarg


Apistar-contrib: Extra batteries for API Star 0.4+ (Session and CSRF)
#5

@tom do you have any plans/ideas for addressing this view decorator issue?


#6

I’ve confirmed to myself that using functools.wraps for decorators does work with inspect.signature as expected, so it’s not clear to me what benefit using __annotations__ would provide.

If someone want to provide an example, then perhaps.


#7

@tom I am trying to something close to this nonsensical example:

def check_my_cookie(func):
    @functools.wraps(func)
    def wrapper(*args, cookie: http.Header, **kwargs):
        if cookie:
            cookies = parse_cookie(cookie)
            cookie_value = cookies.get('my_cookie')
            if not cookie_value:
                raise BadRequest
        return func(*args, **kwargs) 
    return wrapper


@check_my_cookie
def my_view(some_param: http.QueryParam):
    return {'hello': some_param}

I need some way to let the dependency injector know that I have added more attributes and annotations. functools.wraps just copies the inner func. However, __annotations__ is mutable and can be modified like this:

wrapper.__annotations__['cookie'] = http.Header

This doesn’t necessarily need to be the solution, but I guess the ultimate problem is that we need a way to let view decorators communicate with the dependency injector. Possible from some other attribute set on the view.