[Python-Dev] decorator support

[Kevin Jacobs]

Raymond Hettinger wrote:

>In my experiments with decorators, it is common to wrap the original
>function with a new function.
>[...]
>So, it would be nice if there were some support for carrying forward the
>argspec to inform help(), calltips(), and inspect().
>
>FWIW, I do know that with sufficient gyrations a decorator could do this
>on its own, but it is way too difficult for general use.
>  
>
The way I look at it, this is a situation analogous to symbolic links
at the filesystem level.  My first intuition is to add a function attribute,
say func.__proxyfor__ that indicates that a function is a proxy for
another.  That way, introspection and reflection tools that understand
that attribute can extract information from both the proxy and the
proxied functions without too much behind the scenes black magic.

Also note that this is not just an issue with decorators -- I run
into it frequently when writing metaclasses.  I tend not to copy
the proxied functions dictionary, attributes, etc.  Rather, I
re-introduce the proxied function into the class namespace under
a different name.  e.g., a Synchronized metaclass, which
implements thread synchronization, replaces each method
with a proxy that performs the locking gymnastics.  However,
the original methods are accessible via '_<name>_unlocked'.
This allows documentation and introspection tools to find
and output information on the true function signatures.  All
that is missing is the '__proxyfor__' attribute to link them
and tools that interpret it.

I realize that decorators are limited to dealing with one name
binding at a time without resorting to _getframe (unlike
metaclasses, which can rummage through the entire class
with impunity).  Thus, I'd like to keep brainstorming on
how to address this issue.  Once we have something good,
I'm even up for contributing some of the necessary code.


-Kevin