[Python-Dev] Proposed tweaks to functools.wraps

[Benjamin Peterson]

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 update_wrapper
> 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.update_wrapper 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