[Python-Dev] PEP 318: Let's propose some useful built-in decorators

[Phillip J. Eby]

At 03:15 PM 4/2/04 -0500, Kevin Jacobs wrote:
>Guido van Rossum wrote:
>
>>>>class func_attrs(objects):
>>>>
>>>>     def __init__(self, **kwds):
>>>>         self.attrs = kwds
>>>>
>>>>     def __call__(self, funcobj):
>>>>         funcobj.__dict__.update(self.attrs)
>>>>
>>>>
>>>Did you leave out the 'return funcobj' from the end of __call__?  I
>>>thought that decorators were supposed to be inherently cooperative,
>>>and should return their modified funcobj, or a new func-like-obj.
>>>
>>
>>Sorry, you're right.  (I've been thinking of interpreting a None
>>result as "keep the input object" but the code generation would be too
>>messy.
>>
>
>Cool.  And now that I have my pedantic hat on, I may as well go all 
>out.  First,
>why call it func_attrs, when staticmethod and classmethod are underscoreless?
>Second, I know it is effectively the same, but shouldn't the .update line use
>vars(funcobj) instead of funcobj.__dict__?   This is something that I am asked
>(often!) by my Python students.  I use vars(obj) since it looks less magical.

For that matter, updating the dictionary is nice as a quick trick, but what 
if the object doesn't *have* a dictionary?  Using setattr would be safer, 
if this is intended to be subclassed.  Suppose, for example, that 
'synchronized' actually returns a callable wrapper written in C, rather 
than a function object, and that wrapper then delegates setattr to the 
thing it wraps?

So, I think using setattr would be safer, and __dict__.update() is 
premature optimization, given that function object creation and decorator 
invocation isn't likely to be a performance bottleneck.