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

Benjamin Peterson benjamin at python.org
Wed Aug 11 04:39:42 CEST 2010

2010/8/10 Nick Coghlan <ncoghlan at gmail.com>:

Based on a pair of tracker issues (#3445 and #9396) I'm considering a couple of adjustments to functools.wraps for 3.2.

The first (#3445) is a request from ages ago to make updatewrapper more forgiving when it encounters a missing attribute. Instead of throwing AttributeError (as it does now), it would just skip the missing attribute. This would allow wraps to be used with other callables that don't fully mimic the function API. I was initially opposed to the idea, but over time I've come to think this is a case where practicality beats purity (since that really sums up functools.wraps in general - it is already the case that the copied info isn't quite right for the decorated function, but it's still better than using the wrapper function's own metadata).

That seems fine. With class decorators, I suppose it might be possible to have something like:

def class_deco(cls): @functools.wraps(cls) class Spam: pass @class_deco class Eggs: pass

which would require ignoring the absence of annotations.

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.

-- Regards, Benjamin

More information about the Python-Dev mailing list