[Python-Dev] Proposed tweaks to functools.wraps

[Nick Coghlan]

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

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