Issue1161819
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2005-03-12 04:21 by ncoghlan, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
func_update_meta.diff | ncoghlan, 2005-03-12 04:21 | Add update_meta method to function objects |
Messages (6) | |||
---|---|---|---|
msg47930 - (view) | Author: Nick Coghlan (ncoghlan) * | Date: 2005-03-12 04:21 | |
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) |
|||
msg47931 - (view) | Author: Michael Chermside (mcherm) | Date: 2005-03-14 13:34 | |
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. |
|||
msg47932 - (view) | Author: Anders J. Munch (andersjm) | Date: 2005-03-22 12:19 | |
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. |
|||
msg47933 - (view) | Author: Nick Coghlan (ncoghlan) * | Date: 2005-03-22 13:15 | |
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). |
|||
msg47934 - (view) | Author: Anders J. Munch (andersjm) | Date: 2005-03-22 21:12 | |
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. |
|||
msg47935 - (view) | Author: Nick Coghlan (ncoghlan) * | Date: 2006-03-24 13:13 | |
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. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:10 | admin | set | github: 41684 |
2005-03-12 04:21:09 | ncoghlan | create |