[Patches] [ python-Patches-1161819 ] Add method to function objects to simplify decoration

[SourceForge.net]

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