[Python-Dev] decorator module in stdlib?

[Michele Simionato]

On Wed, Apr 8, 2009 at 7:51 PM, Guido van Rossum <guido at 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.