Repository navigation
inspect.unwrap() does not work with types with the __wrapped__ data descriptor #112006
Description
Activity
- changed the title
[-]inspect.unwrap() does not work with types with the `__wrapper__` data descriptor[/-][+]inspect.unwrap() does not work with types with the `__wrapped__` data descriptor[/+]on Feb 15, 2024 After more consideration I think that option 1 is the right one. A class should never be a wrapper with the
__wrapper__link, because this makes all instances wrappers of the same wrapped object. Even if this trick is used to make all instances the wrappers of the same wrapped object, the class is different from its instances.- added a commit that references this issue
on Feb 26, 2024 - added a commit that references this issue
on Jun 21, 2024 I see it's referenced above (specifically with:
A class should never be a wrapper with the wrapper link, because this makes all instances wrappers of the same wrapped object.
but just having found this issue, I'm left a bit confused what the suggested fix is, as this change does break what seems to me to be the simple use of
wrapswith a type. Specifically:from functools import wraps import inspect class Foo: pass @wraps(Foo, updated=()) class Bar: pass print(inspect.unwrap(Bar) is Foo)
on py3.10 returns True and on later versions returns False.
Other than ignoring
inspect.unwrapand simply following__wrapped__manually, what's the intended solution after this change for cases where one is wrapping a type, and never cares to unwrap instances?Reacted by kernc
Bug report
inspect.unwrap()follows the chain by links__wrapped__and returns the last item in a chain or the original object if it does not have a__wrapped__attribute (there is also additional stop predicate and protection against loops, but it is unrelated). It works well in most cases, except with a type that has the__wrapped__data descriptor.For example the following code
prints
The former output is correct,
W(chr)wrapschr. But the latter is wrong: theWtype does not wrap apropertyobject.It is not hypothetical issue.
staticmethodandclassmethodhave now (bpo-43682/#87848) the__wrapped__attribute.inspect.signature()usesinspect.unwrap(), and it cannot supportstaticmethodandclassmethodeven if they get correct__text_signature__.inspect.getsourcelines()also usesinspect.unwrap()indirectly and can fail with Python classes with the__wrapped__attribute.inspect.unwrap()should stop before such attribute. But how to detect such case? There are several ways:funcis a class.pickledoes it for its special methods, this is why classes are handled separately from instances. But it means thatfunctools.wraps(),staticmethodandclassmethodcannot be used to decorate classes. Although if they are currently used, the result can be weird, because instances will have the same__wrapped__attribute as a class. I do not know how often wrapped classes are used in the real code, but there is a test for this. It may be the right way at the end, although it can break some questionable code.func.__wrapped__is a data descriptor. I afraid that it will affect multidecorated properties.func.__wrapped__is not callable. Do not know what can be consequences.Maybe there are other ways?
Linked PRs