Issue 20691: inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API (original) (raw)
Created on 2014-02-19 22:21 by yselivanov, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (8)
Author: Yury Selivanov (yselivanov) * 
Date: 2014-02-19 22:21
In the issue #20684, Nick had an idea of exposing 'follow_wrapper_chains' option to the public API. This might be actually very useful.
Author: Yury Selivanov (yselivanov) *
Date: 2014-03-27 23:02
So... should we expose two keyword only parameters for Signature.from_callable() and signature():
- 'follow_wrapped=True' to follow wrapped chains;
- 'keep_bound_arg=False' to skip/include first bound arg?
Author: Yury Selivanov (yselivanov) *
Date: 2015-05-19 04:44
Nick, what do you think of this one?
Author: Alyssa Coghlan (ncoghlan) *
Date: 2015-05-19 06:24
I like the idea of the following signature:
def signature(callable, *, follow_wrapped=True):
...I'm less convinced about exposing the flag to optionally show the first positional arg for bound methods, as that's currently specific to method objects and builtins, rather than being a protocol like wrapped that any callable can readily implement.
If we did do that, then I think we should follow the convention of naming it after an attribute we look for (in this case, self) rather than limiting it to a specific type, and also make it default to true for consistency.
That would give us:
def signature(callable, *, follow_wrapped=True, omit_bound_self=True):
...The "omit_bound_self" flag would then be documented along the following lines: "If 'omit_bound_self' is true, and the callable has a 'self' attribute set to a value other than None, then the first positional argument will be hidden from the displayed signature. Setting this to false means that bound methods will be displayed the same"
However, as noted, I doubt the latter is worth it - let's just expose the flag to decide whether to resolve wrapper chains or not, and leave the inclusion of the already bound value in the reported signature solely as a legacy behaviour of getargspec and getfullargspec.
Author: Yury Selivanov (yselivanov) *
Date: 2015-05-19 21:20
Nick,
However, as noted, I doubt the latter is worth it - let's just expose the flag to decide whether to resolve wrapper chains or not, and leave the inclusion of the already bound value in the reported signature solely as a legacy behaviour of getargspec and getfullargspec.
I agree. Please take a look at the attached patch.
BTW, Signature.from_function and Signature.from_builtin aren't documented. Do you think it's OK if I drop them? There is no good use case for them (and we have Signature.from_callable in 3.5).
Also, while working on the patch, I noticed that functools.wraps copies annotations attribute. This is really strange. Most of the times, wrapper in python has signature akin to (*args, **kwargs). Blindly copying annotations doesn't make any sense. What do you think about this?
Author: Yury Selivanov (yselivanov) *
Date: 2015-05-19 21:26
Do you think it's OK if I drop them?
Dropping == DeprecationWarning
Author: Roundup Robot (python-dev) 
Date: 2015-05-20 18:30
New changeset 0c298f1ee3f6 by Yury Selivanov in branch 'default': Issue 20691: Add follow_wrapped arg to inspect.signature/from_callable. https://hg.python.org/cpython/rev/0c298f1ee3f6
Author: Yury Selivanov (yselivanov) *
Date: 2015-05-20 18:31
Closing this one.
History
Date
User
Action
Args
2022-04-11 14:57:58
admin
set
github: 64890
2015-05-20 18:31:21
yselivanov
set
status: open -> closed
resolution: fixed
messages: +
stage: resolved
2015-05-20 18:30:48
python-dev
set
nosy: + python-dev
messages: +
2015-05-19 21:26:38
yselivanov
set
messages: +
2015-05-19 21:20:15
yselivanov
set
files: + sig_wrapped.patch
keywords: + patch
messages: +
2015-05-19 06:24:48
ncoghlan
set
messages: +
2015-05-19 04:44:38
yselivanov
set
messages: +
2014-03-27 23:02:09
yselivanov
set
messages: +
2014-02-19 22:21:01
yselivanov
create