2010/8/10 Nick Coghlan <ncogh...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
