Sometimes it is useful to be able to check which decorators are already applied to a function, especially when you are constructing them dynamically. I am proposing that for all decorators in Python would be suggested that they maintain a list of used decorators on a function. It is most useful when all decorators do this.

It is the same reasoning why `inspect` module is in Python - to be able to inspect Python structures, to have this possibility. If you do not want it then you do can use Python structures as they were given to you. But you have an option to inspect them.

And I would like the same to see from decorators. It is not really so important that all decorators update this. If they would not then they would be hidden from inspection. But if developer wants to use inspection then he would choose such decorators which use this (or change them in this way). If all default Python's decorators would already be such it would be much easier to use them.

This could be implement by changing `wraps` function to pass over also the (for example) `__DECORATORS__` attribute of a function to a wrapped function and add this new decorator to a list, `__DECORATORS__`.

By default in a list ids of decorators would be maintained, but this could be overridden by `id` attribute of `wraps` function so that decorator can represent itself in some special way, for example as a tuple of its id and some significant parameters.

I have added people from the nosy list of #9567. What do you think about this idea?

How?

It was easy for wraps to add the __wrapped__ attribute, since it has access to both the wrapping function and the function being wrapped.

But it hasn't got a clue as to the identity of the decorator that is applying the wrapper.

Absent a concrete suggestion for how to actually do this cleanly, I'm inclined to reject the idea as being infeasible given the way decorators are applied.

I concur with Nick.  If you want to develop your __DECORATORS__ idea further, it should be done off-list.  ISTM, this is more of a shot in the dark than a concrete plan to solve known, real problems.

Here is the concrete code how I imagined that:

http://code.djangoproject.com/ticket/13854

So this would be not made in code of `wraps` function, but would be contract for implementers to do it, if they want to be visible (maybe they still do not want that). And all built-in decorators should do that then.

That's a lot of boilerplate for minimal gain. The Django commenter was right - proposals that start with "everybody in the world needs to do X differently from the way they do it now for this to be useful" aren't ever likely to gain much traction.