[Python-Dev] decorator module in stdlib?
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 ;-(
> 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