[Python-ideas] Proposal for new-style decorators

[Christophe Schlick]

On Wed, Apr 27, 2011 at 6:26 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Attacking (some aspects of) the same problem from a different angle,
> note that part of the motivation of PEP 362 (function signature
> objects) is to allow functools.wraps to be more effective at
> preserving signature information, and to allow similar gains for
> functools.partial. It also allows signature checks to be performed
> independently of actually calling functions (via the Signature.bind()
> method).

Exactly, there are really two complementary solutions to tackle the problem:

1 - copy *all* information from the undecorated function to the
undecorated one. As you say, this requires to extend the '@wraps' tool
to include signature copying (and with function signature objects of
PEP 362 this would be trivial)

2 - let the decorated function as is without copying anything, but
provide a simple, systematic solution to get the
name/signature/docstring of the undecorated function. That's the idea
of my proposal

> Actually *writing* decorators is still somewhat cumbersome by default,
> but if anything were to happen on that front, the most likely would be
> to ask Michele about making the decorators module part of the standard
> library.

As I said in my initial post, there was quite a long discussion in
python-dev exactly about that idea. I finally get the reference to the
topic. Here is the first post of that thread:

http://mail.python.org/pipermail/python-dev/2009-April/088387.html

and here is an extract of what Guido thinks about it:
---
On Wed, Apr 8, 2009 at 7:51 PM, Guido van Rossum <guido at python.org> wrote:

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

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

Reading that thread was actually the starting point, several months
ago, when I came out with the idea of NSD. The initial question was:
"so, if copying signature is not a step in the right direction, is
there any alternative that offers similar functionality?". In fact,
reducing the boilerplate of decorator pattern only came as a
side-effect

CS