metaclass conflict when deriving from decorated classes about wrapt HOT 5 CLOSED

Derive from A.__wrapped__.

from wrapt.

If the decorator should somehow apply to the derived class, then use of a traditional meta class construct may be more appropriate.

from wrapt.

Hi Graham, thanks for the hints!

So using A.__wrapped__ would certainly work, but it starts to introduce "advanced" knowledge into how to apply our decorator, a more seamless option would be great.

And using metaclasses would obviously be abandoning our decorator pattern for this use case entirely. Not the end of the world, but certainly second prize.

Can I push you a little further and ask if you can imagine a way we could extend wrapt.decorator such that this would work seamlessly?

I ask because the decorator in concern is one written using your "universal" pattern and exists with the express goal of providing memoization in a wide variety of situations. We use simple behavioural flags passed to a single decorator which handles functions, classes, methods etc. The simplicity of application is key for us (lots of devs, large codebase).

Thanks,
Matt

from wrapt.

What is the decorator doing in the case of being applied to a class?

And no, I don't know of any way of having class derivation somehow automagically follow __wrapped__. It is one of the parts of the Python object model that you can't override.

from wrapt.

Closing out this old issue. Accessing __wrapped__ when inheriting from a decorator class was no longer required since wrapt 1.12.0, provided you are using Python 3.7 or newer. There is no solution for older Python versions.

• https://wrapt.readthedocs.io/en/latest/issues.html#deriving-from-decorated-class

from wrapt.