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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4