[Python-Dev] decorator support (original) (raw)

Kevin Jacobs jacobs at theopalgroup.com
Sun Sep 5 15:13:41 CEST 2004

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 '__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

More information about the Python-Dev mailing list