-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API #64890
Comments
In the issue bpo-20684, Nick had an idea of exposing 'follow_wrapper_chains' option to the public API. This might be actually very useful. |
So... should we expose two keyword only parameters for Signature.from_callable() and signature():
|
Nick, what do you think of this one? |
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. |
Nick,
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? |
Dropping == DeprecationWarning |
New changeset 0c298f1ee3f6 by Yury Selivanov in branch 'default': |
Closing this one. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: