Larry Hastings <la...@hastings.org> added the comment:
Okay, so, I considered the problem for a while, and I have a reasonable theory
about what follow_wrapper_chains was for in the first place.
If you have a generic decorator, like functools.cache(), it usually looks like
this:
def my_decorator(fn):
def generic_version(*args, **kwargs):
args, kwargs = do_something(args, kwargs)
return fn(*args, **kwargs)
return generic_version
@my_decorator
def add_five(i):
return i+5
If you take the signature of add_five, you'd get (*args, **kwargs), because
that's the signature of the wrapper function returned by the decorator. The
decorator doesn't change the parameters of the function, but because of how
decorators work it can occlude the proper function signature. In that
instance, follow_wrapper_chains does the right thing, and as a result you get a
precise function signature.
(Of course, it would do the wrong thing if your hand-written decorator *also*
behaved like a partial application, adding in its own hard-coded arguments, so
that the resulting function signature changed.)
Still, obviously it's doing the wrong thing when it comes to
functools.partial() functions.
My suspicion is that I'm the rare individual who actually uses update_wrapper
on a functools.partial object. So maybe we have the situation here where,
yeah, it's a bug, and we can fix it without causing further breakage.
Maybe we can loop in someone who works on a popular runtime function
introspection library (FastAPI, Pydantic) to see if they have any take on it.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue46761>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
