Actually, what is the problem with having all decorators add a __decorated__ to the function that ultimately gets returned, pointing to the function they decorated? I guess I never saw that discussion. Perhaps set it to None when the decorator is the same as the decorated (no wrapping involved). The alternative is sifting through closures, trying to figure out which is the decorated function. Finding the original decorated function has been a real pain, particularly when a function has more than one closure cell.
-eric -----Original Message----- From: python-dev-bounces+esnow=verio....@python.org [mailto:python-dev-bounces+esnow=verio....@python.org] On Behalf Of Nick Coghlan Sent: Tuesday, August 10, 2010 8:31 PM To: python-dev@python.org Subject: [Python-Dev] Proposed tweaks to functools.wraps 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). 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. Thoughts? Concerns? Better ideas? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/esnow%40verio.net This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. _______________________________________________ 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
