[Python-Dev] Proposed tweaks to functools.wraps (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Aug 11 05:06:59 CEST 2010

On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson <benjamin at python.org> wrote:

The second (#9396) came up in the context of the new cache decorators added to functools, and allowing applications to choose their own caching strategies. I suggested exposing the original (uncached) function, and Raymond suggested that the easiest way to enable that would be for functools.updatewrapper to add a new attribute that provides a reference to the original function. Some time back, we considered doing this automatically as an integral part of decoration, but decided that wasn't appropriate. However, building it into the explicit wrapping functions makes sense to me. To avoid namespace conflicts, I plan to use "wraps" as the name for the reference to the original function. Namespace conflict with what? I would prefer "wraps" unless it's standardized as a behavior for all decorators.

With any existing attributes on the function - there's a reason update_wrapper includes a call to dict.update(). Using a normal attribute means having to consider the implications of what to do if the object being wrapped already has an attribute with that name. By using a system-reserved name, we can duck that question entirely.

My recollection of previous discussions is that the reason we didn't make it an implicit part of the decoration process is because not all decoration is about creating wrapper functions, so it gets messy trying to decide whether or not it should be added. The explicit use of the @wraps decorator when creating the wrapper function resolves that particular concern nicely.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list