Skip to content
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

Closed
1st1 opened this issue Feb 19, 2014 · 8 comments
Closed
Assignees
Labels
type-feature A feature request or enhancement

Comments

@1st1
Copy link
Member

1st1 commented Feb 19, 2014

BPO 20691
Nosy @ncoghlan, @larryhastings, @1st1
Files
  • sig_wrapped.patch
  • 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:

    assignee = 'https://github.com/1st1'
    closed_at = <Date 2015-05-20.18:31:21.567>
    created_at = <Date 2014-02-19.22:21:01.453>
    labels = ['type-feature']
    title = "inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API"
    updated_at = <Date 2015-05-20.18:31:21.566>
    user = 'https://github.com/1st1'

    bugs.python.org fields:

    activity = <Date 2015-05-20.18:31:21.566>
    actor = 'yselivanov'
    assignee = 'yselivanov'
    closed = True
    closed_date = <Date 2015-05-20.18:31:21.567>
    closer = 'yselivanov'
    components = []
    creation = <Date 2014-02-19.22:21:01.453>
    creator = 'yselivanov'
    dependencies = []
    files = ['39435']
    hgrepos = []
    issue_num = 20691
    keywords = ['patch']
    message_count = 8.0
    messages = ['211668', '214992', '243556', '243558', '243627', '243629', '243682', '243683']
    nosy_count = 4.0
    nosy_names = ['ncoghlan', 'larry', 'python-dev', 'yselivanov']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue20691'
    versions = ['Python 3.5']

    @1st1
    Copy link
    Member Author

    1st1 commented Feb 19, 2014

    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.

    @1st1 1st1 self-assigned this Feb 19, 2014
    @1st1 1st1 added the type-feature A feature request or enhancement label Feb 19, 2014
    @1st1
    Copy link
    Member Author

    1st1 commented Mar 27, 2014

    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?

    @1st1
    Copy link
    Member Author

    1st1 commented May 19, 2015

    Nick, what do you think of this one?

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented May 19, 2015

    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.

    @1st1
    Copy link
    Member Author

    1st1 commented May 19, 2015

    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?

    @1st1
    Copy link
    Member Author

    1st1 commented May 19, 2015

    Do you think it's OK if I drop them?

    Dropping == DeprecationWarning

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented May 20, 2015

    New changeset 0c298f1ee3f6 by Yury Selivanov in branch 'default':
    bpo-20691: Add follow_wrapped arg to inspect.signature/from_callable.
    https://hg.python.org/cpython/rev/0c298f1ee3f6

    @1st1
    Copy link
    Member Author

    1st1 commented May 20, 2015

    Closing this one.

    @1st1 1st1 closed this as completed May 20, 2015
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants