Patches item #1161819, was opened at 2005-03-12 14:21 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161819&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Add method to function objects to simplify decoration Initial Comment: When decorating a function without changing the signature, it is generally appropriate to preserve the metadata from original function. This currently involves copying the docstring and name and updating the function attribute dict manually. This patch adds an "update_meta" method to function objects which modifies the current function to masquerade as the original function. Test & documentation patches still to come. (Although the docstring text could also be used for the documentation) ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-24 23:13 Message: Logged In: YES user_id=1038590 We're not going to do it this way - most likely will be a standard decorator for creating well-behaved decorators. ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2005-03-23 07:12 Message: Logged In: YES user_id=384806 Taken as behind-the-scenes infrastructure, not intended to be used directly, why not a pure-Python standalone function instead, for easier maintenance? Also, that would avoid discriminating against non-function callables. Although you can't use decorator syntax with non-function callables, the decorator functions themselves need not have that limitation. The case for decorator-style: 1) When used as a decorator there is no risk of getting the argument order wrong, even if it does change the argument. 2) It plays better with the open-closed principle, allowing decoratees to provide custom meta-updaters. Of course "update" in the name would be misleading, better (supply|imbue|impress)_meta. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-03-22 23:15 Message: Logged In: YES user_id=1038590 It's an interesting idea, but I'm extremely uncomfortable with the idea of a method that mutates the argument instance passed in rather than the instance that owns the method. Instead, I'd prefer to keep the current signature, and view func.update_metadata() as infrastructure that things like @simple_decorator and @decorating can build on top of. So long as the method is kept in sync with additions to the set of metadata, those two decorators would then be kept in sync for free (which is the whole point). ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2005-03-22 22:19 Message: Logged In: YES user_id=384806 If self and argument are swapped, making update_meta a method on the source of information instead of the target, then the bound method will be usable as a decorator. See "Decorator decorator" in http://www.python.org/moin/PythonDecoratorLibrary for the same idea as a free function. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-03-14 23:34 Message: Logged In: YES user_id=99874 Nice... thanks. But I have to ask: is this really the right set of metadata to be updating? Here are a few things that perhaps ought be copied by update_meta: f.__name__ (already included) f.__doc__ (already included) f.__dict__ (already included) f.__module__ (probably should include) f.func_code.co_filename (to match f.__name__, but I'd leave it alone) there's also the annoying fact that in IDLE (and in some other python-aware IDEs) one can see the argument signature for a function as a "tool tip" or other hint. Very handy that, but if a decorator is applied then all you will see is "func(*args, **kwargs)" which is less than helpful. I'm not sure whether this CAN be duplicated... I believe it is generated by examining the following: f.func_code.co_argcount f.func_code.co_varnames f.func_code.co_flags & 0x4 f.func_code.co_flags & 0x8 ...and I suspect (experimentation seems to confirm this) that if you mangle these then the code object won't work correctly. If anyone's got a suggestion for fixing this, I'd love to hear it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1161819&group_id=5470 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
