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

Phillip J. Eby pje at telecommunity.com
Fri Apr 2 15:35:26 EST 2004

At 03:15 PM 4/2/04 -0500, Kevin Jacobs wrote:

Guido van Rossum wrote:

class funcattrs(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 funcattrs, 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.

More information about the Python-Dev mailing list