On Wed, Apr 8, 2009 at 7:51 PM, Guido van Rossum <gu...@python.org> wrote: > > There was a remark (though perhaps meant humorously) in Michele's page > about decorators that worried me too: "For instance, typical > implementations of decorators involve nested functions, and we all > know that flat is better than nested." I find the nested-function > pattern very clear and easy to grasp, whereas I find using another > decorator (a meta-decorator?) to hide this pattern unnecessarily > obscuring what's going on.
I understand your point and I will freely admit that I have always had mixed feelings about the advantages of a meta decorator with respect to plain simple nested functions. I see pros and contras. If functools.update_wrapper could preserve the signature I would probably use it over the decorator module. > I also happen to disagree in many cases with decorators that attempt > to change the signature of the wrapper function to that of the wrapped > function. While this may make certain kinds of introspection possible, > again it obscures what's going on to a future maintainer of the code, > and the cleverness can get in the way of good old-fashioned debugging. Then perhaps you misunderstand the goal of the decorator module. The raison d'etre of the module is to PRESERVE the signature: update_wrapper unfortunately *changes* it. When confronted with a library which I do not not know, I often run over it pydoc, or sphinx, or a custom made documentation tool, to extract the signature of functions. For instance, if I see a method get_user(self, username) I have a good hint about what it is supposed to do. But if the library (say a web framework) uses non signature-preserving decorators, my documentation tool says to me that there is function get_user(*args, **kwargs) which frankly is not enough [this is the optimistic case, when the author of the decorator has taken care to preserve the name of the original function]. I *hate* losing information about the true signature of functions, since I also use a lot IPython, Python help, etc. >> I must admit that while I still like decorators, I do like them as >> much as in the past. Of course there was a missing NOT in this sentence, but you all understood the intended meaning. > (All this BTW is not to say that I don't trust you with commit > privileges if you were to be interested in contributing. I just don't > think that adding that particular decorator module to the stdlib would > be wise. It can be debated though.) Fine. As I have repeated many time that particular module was never meant for inclusion in the standard library. But I feel strongly about the possibility of being able to preserve (not change!) the function signature. > To me, introspection is mostly useful for certain > situations like debugging or interactively finding help, but I would > hesitate to build a large amount of stuff (whether a library, > framework or application) on systematic use of introspection. In fact, > I rarely use the inspect module and had to type help(inspect) to > figure out what you meant by "signature". :-) I guess one reason is > that in my mind, and in the way I tend to write code, I don't write > APIs that require introspection -- for example, I don't like APIs that > do different things when given a "callable" as opposed to something > else (common practices in web frameworks notwithstanding), and > thinking about it I would like it even less if an API cared about the > *actual* signature of a function I pass into it. I like APIs that say, > for example, "argument 'f' must be a function of two arguments, an int > and a string," and then I assume that if I pass it something for 'f' > it will try to call that something with an int and a string. If I pass > it something else, well, I'll get a type error. But it gives me the > freedom to pass something that doesn't even have a signature but > happens to be callable in that way regardless (e.g. a bound method of > a built-in type). I do not think everybody disagree with your point here. My point still stands, though: objects should not lie about their signature, especially during debugging and when generating documentation from code. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
