[Python-Dev] decorator module in stdlib? (original) (raw)

Guido van Rossum guido at python.org
Wed Apr 8 19:51:55 CEST 2009

On Wed, Apr 8, 2009 at 12:17 AM, Michele Simionato <michele.simionato at gmail.com> wrote:

On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich <jackdied at gmail.com> wrote:

Plus he's a softie for decorators, as am I.

This worries me a bit.

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 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.

I must admit that while I still like decorators, I do like them as much as in the past. I also see an overuse of decorators in various libraries for things that could be done more clearly without them ;-(

Right.

But this is tangential.

(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.)

What I would really like to know is the future of PEP 362, i.e. having a signature object that could be taken from an undecorated function and added to the decorated function. I do not recall people having anything against it, in principle, and there is also an implementation in the sandbox, but after three years nothing happened. I guess this is just not a high priority for the core developers.

That's likely true. 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 will probably regret saying this. So be it. :-)

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list