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: Deprecate getfullargspec? #64637

Closed
1st1 opened this issue Jan 29, 2014 · 40 comments
Closed

inspect: Deprecate getfullargspec? #64637

1st1 opened this issue Jan 29, 2014 · 40 comments
Labels
type-feature A feature request or enhancement

Comments

@1st1
Copy link
Member

1st1 commented Jan 29, 2014

BPO 20438
Nosy @brettcannon, @ncoghlan, @larryhastings, @nedbat, @bitdancer, @berkerpeksag, @1st1, @matrixise, @vedgar, @untitaker, @hugovk
PRs
  • bpo-28814: Undeprecate inadvertantly deprecated inspect function. #122
  • [3.6] bpo-28814: Undeprecate inadvertently deprecated inspect functions. (#122) #243
  • [3.5] bpo-28814: Undeprecate inadvertently deprecated inspect functions. (#122) #244
  • bpo-45320 Remove deprecated inspect methods #28618
  • Dependencies
  • bpo-25486: Resurrect inspect.getargspec() in 3.6
  • Files
  • issue20438_deprecate_inspect-getfullargspec.patch
  • issue20438_deprecate_inspect_getfullargspec-2.patch
  • getargspec.diff
  • 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 = None
    closed_at = <Date 2015-05-22.15:39:20.106>
    created_at = <Date 2014-01-29.17:00:12.946>
    labels = ['type-feature']
    title = 'inspect: Deprecate getfullargspec?'
    updated_at = <Date 2021-09-29.12:48:03.923>
    user = 'https://github.com/1st1'

    bugs.python.org fields:

    activity = <Date 2021-09-29.12:48:03.923>
    actor = 'hugovk'
    assignee = 'none'
    closed = True
    closed_date = <Date 2015-05-22.15:39:20.106>
    closer = 'yselivanov'
    components = []
    creation = <Date 2014-01-29.17:00:12.946>
    creator = 'yselivanov'
    dependencies = ['25486']
    files = ['34877', '34890', '39459']
    hgrepos = []
    issue_num = 20438
    keywords = ['patch']
    message_count = 40.0
    messages = ['209658', '209664', '209665', '209692', '216317', '216318', '216327', '216328', '216333', '216337', '216339', '216340', '216341', '216342', '216365', '216385', '216387', '216621', '217581', '243777', '243835', '243848', '243850', '243851', '243852', '243853', '250805', '250808', '253434', '253436', '253473', '253475', '253500', '253501', '254892', '254899', '282173', '288334', '290422', '290425']
    nosy_count = 12.0
    nosy_names = ['brett.cannon', 'ncoghlan', 'larry', 'nedbat', 'r.david.murray', 'python-dev', 'berker.peksag', 'yselivanov', 'matrixise', 'veky', 'untitaker', 'hugovk']
    pr_nums = ['122', '243', '244', '28618']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue20438'
    versions = ['Python 3.5']

    @1st1
    Copy link
    Member Author

    1st1 commented Jan 29, 2014

    Should we finally deprecate getfullargspec? With the AC and positional-only parameters support, getfullargspec doesn't provide full information anymore.

    By deprecation I mean changing its existing note "Consider using the new Signature Object interface, which provides a better way of introspecting functions." to "Deprecated since version 3.4: Use inspect.signature() instead".

    @1st1 1st1 added the type-feature A feature request or enhancement label Jan 29, 2014
    @brettcannon
    Copy link
    Member

    brettcannon commented Jan 29, 2014

    I vote deprecation with no stated plans of removal

    @brettcannon
    Copy link
    Member

    brettcannon commented Jan 29, 2014

    Although I say do it in 3.5.

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Jan 29, 2014

    As Brett said - let's do a documented deprecation in 3.5.

    @matrixise
    Copy link
    Member

    matrixise commented Apr 15, 2014

    In this patch, I deprecate the inspect.getfullargspec function in the documentation and raise an warnings.warn with DeprecationWarning.

    Need feedback, because the inspect.getargspec() informs the user that it can use the getfullargspec() and I think we should use inspect.signature instead of inspect.getfullargspec() and inspect.getargspec().

    Thank you

    @matrixise
    Copy link
    Member

    matrixise commented Apr 15, 2014

    Here is the output of my test:

    ./python3.5 -Wd test.py
    test.py:9: DeprecationWarning: Deprecated
    warnings.warn('Deprecated', DeprecationWarning)

    /private/tmp/python/lib/python3.5/inspect.py:955: DeprecationWarning: Use inspect.signature() instead of inspect.getfullargspec()
    warnings.warn("Use inspect.signature() instead of inspect.getfullargspec()", DeprecationWarning)
    FullArgSpec(args=[], varargs='args', varkw='kwargs', defaults=None, kwonlyargs=[], kwonlydefaults=None, annotations={})

    @brettcannon
    Copy link
    Member

    brettcannon commented Apr 15, 2014

    I was thinking about suggesting we don't code deprecate getfullargspec() but the function seems to be new to Python 3 and so that worry for Python 2/3 code is not founded.

    @1st1
    Copy link
    Member Author

    1st1 commented Apr 15, 2014

    How about we deprecate with a warning getfullargspec(); deprecate getargspec() in docs only (in 3.6 we'll fully deprecate all function parameters API except Signature)?

    @matrixise
    Copy link
    Member

    matrixise commented Apr 15, 2014

    Just one thing, how do you work for the deprecation?

    1. you deprecate in the doc for 3.5?
    2. you deprecate in the code for 3.6?
    3. you remove the code in 3.7?

    What's the strategy in this case or in general?

    Thanks

    @brettcannon
    Copy link
    Member

    brettcannon commented Apr 15, 2014

    How warnings are handled vary from case to case. Typically its documentation-only if we want to warn people that they shouldn't use something because there is a better alternative but the code is not fundamentally broken and its in Python 2. If there is something wrong with it or it's just in Python 3 then a deprecation warning with a decided amount of time for when the code will be removed.

    @matrixise
    Copy link
    Member

    matrixise commented Apr 15, 2014

    ok, so in this case, I can only change the documentation with a ".. deprecated:". But for the future, how can we know we have to deprecate this function for >= 3.6 ? Will you parse the documentation and check there is an deprecation to add in the code?

    Or is there a file with the "future" deprecations?

    Are you agree with the deprecation in the documentation?

    @1st1
    Copy link
    Member Author

    1st1 commented Apr 15, 2014

    I'd +1 for:

    1. Deprecating getfullargsspec in docs;
    2. Deprecating getargspec in docs and code (since it's an ancient and outdated API)

    Brett?

    @matrixise
    Copy link
    Member

    matrixise commented Apr 15, 2014

    Brett,

    If you agree with Yury, I will provide a patch with these tasks.

    @brettcannon
    Copy link
    Member

    brettcannon commented Apr 15, 2014

    Since getfullargspec is new in Python 3 and inspect.signature fundamentally improves things in Python 3 due to Argument Clinic I would say go ahead and code deprecate getfullargspec (we can do a DeprecationWarning for 3.5 and 3.6 and remove in 3.7; people needing compatibility can just use getargspec). As for getargspec, it was already deprecated so just leave it deprecated and update its message to say to use inspect.signature.

    As for keeping track of this stuff, Stéphane, as part of the test that makes sure the warning is raised, add to that test -- don't need a separate method -- some code that will fail if the function exists in Python 3.7 or later.

    @matrixise
    Copy link
    Member

    matrixise commented Apr 15, 2014

    Need your feedback for this patch

    Thank you

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Apr 15, 2014

    Note that getargspec() depends on getfullargspec() so deprecating the latter *will* cause issues for single-source code (unless they switch to using the funcsigs backport).

    @1st1
    Copy link
    Member Author

    1st1 commented Apr 15, 2014

    Nick, good catch. OK, let's just deprecate it in the docs for 3.5, so people (hopefully) will not write new code with it.

    @larryhastings
    Copy link
    Contributor

    larryhastings commented Apr 16, 2014

    +1 to doc deprecation and adding a DeprecationWarning for 3.5.

    @matrixise
    Copy link
    Member

    matrixise commented Apr 30, 2014

    @larry Hasting: If you check my patch, it's the case where I modify the
    documentation and add a DeprecationWarning in the code.

    @yury Selivanov, @nick Coghlan, @brett Cannon: From your point of views,
    I need to propose a patch just for the documentation, I agree with that.

    @brett Cannon: In the current patch, I implemented a test with the
    python version. If the version is greater or equal than 3.7, in this
    case, I raise an exception.

    I propose to follow the solution of @yury Selinanov, just deprecate the
    function in the documentation and keep the check in the unit test for
    the version.

    Are you agree?

    Thanks

    @1st1
    Copy link
    Member Author

    1st1 commented May 21, 2015

    Please see the new patch.

    So it's time to deprecate getargspec with a warning (was softly deprecated in 3.0).

    getfullargspec() and getcallargs() deprecation is documented.

    I also want to deprecate formatargspec() and formatargvalues(), but Signature does not provide equivalents. Should we add them?

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented May 22, 2015

    New changeset 3a5fec5e025d by Yury Selivanov in branch 'default':
    bpo-20438: Deprecate inspect.getargspec() and friends.
    https://hg.python.org/cpython/rev/3a5fec5e025d

    @1st1 1st1 closed this as completed May 22, 2015
    @berkerpeksag
    Copy link
    Member

    berkerpeksag commented May 22, 2015

    Just a minor comment on the patch:

    + warnings.warn("inspect.getargspec() is deprecated, "
    + "use inspect.signature() instead", DeprecationWarning)

    Can you also add "stacklevel=2"?

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented May 22, 2015

    New changeset 666e5b554f32 by Yury Selivanov in branch 'default':
    bpo-20438: Adjust stacklevel of inspect.getargspec() warning.
    https://hg.python.org/cpython/rev/666e5b554f32

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented May 22, 2015

    New changeset 621e98bfc74b by Yury Selivanov in branch 'default':
    bpo-20438: Add a note about deprecating old inspect APIs to whatsnew.
    https://hg.python.org/cpython/rev/621e98bfc74b

    @1st1
    Copy link
    Member Author

    1st1 commented May 22, 2015

    Thanks Berker!

    @1st1
    Copy link
    Member Author

    1st1 commented May 22, 2015

    I'm copying/pasting my latest commit message on this issue here:

    """Add a note about deprecating old inspect APIs to whatsnew.

    Also, deprecate formatargspec, formatargvalues, and getargvalues
    functions. Since we are deprecating 'getfullargspec' function in
    3.5 (documentation only, no DeprecationWarning), it makes sense
    to also deprecate functions designed to be directly used with it.

    In 3.6 we will remove 'getargsspec' function (was deprecated since
    Python 3.0), and start raising DeprecationWarnings in other
    'getarg*' family of functions. We can remove them in 3.7 or later.

    Also, it is worth noting, that Signature API does not provide 100%
    of functionality that deprecated APIs have. It is important to do
    a soft deprecation of outdated APIs in 3.5 to gather users feedback,
    and improve Signature object."""

    @untitaker
    Copy link
    Mannequin

    untitaker mannequin commented Sep 15, 2015

    It should be properly noted that the API isn't going to be actually removed anytime soon.

    Also I think issuing a warning about this was a mistake. For software that wants to stay compatible with both Python 2 and 3 it's basically useless.

    @untitaker
    Copy link
    Mannequin

    untitaker mannequin commented Sep 15, 2015

    My last comment was in reference to getfullargspec, which is, as far as I understand, not going to be deprecated until after 3.7.

    @nedbat
    Copy link
    Member

    nedbat commented Oct 25, 2015

    I'm confused: the discussion here is mostly about updating docs to note deprecation. Then at the very end, is an off-hand remark about removing getargspec.

    The docs for getargspec currently read, "This function will be removed in Python 3.6." Why? We keep all sorts of old APIs for the sake of backward compatibility, why is this one different?

    @1st1
    Copy link
    Member Author

    1st1 commented Oct 25, 2015

    The docs for getargspec currently read, "This function will be removed in Python 3.6." Why? We keep all sorts of old APIs for the sake of backward compatibility, why is this one different?

    getargspec was deprecated since 3.0. Besides that, it returns incomplete information about function parameters: keyword-only parameters won't be introspected at all for instance.

    Migration path is very simple and clear -- just use getfullargspec (almost 100% backwards compatible), which won't be removed probably till Python 4.

    @bitdancer
    Copy link
    Member

    bitdancer commented Oct 26, 2015

    The thing is, we've adopted a policy that if something exists in python2.7 we shouldn't delete it in python3 until after 2.7 is officially out of maintenance (at the earliest), in order to facilitate single-source porting to python3. That policy was adopted relatively recently, after the deprecation warning mentioning 3.6 was added in this issue, as I recall it.

    @nedbat
    Copy link
    Member

    nedbat commented Oct 26, 2015

    This is the situation I am in: coverage.py uses getargspec in a very simple way in its tooling. I support 2.7 and 3.5, so I have to do this:

    try:
        getargspec = inspect.getfullargspec
    except AttributeError:
        getargspec = inspect.getargspec
    argspec = getargspec(function)
    

    It seems like needless churn.

    @1st1
    Copy link
    Member Author

    1st1 commented Oct 26, 2015

    The thing is, we've adopted a policy that if something exists in python2.7 we shouldn't delete it in python3 until after 2.7 is officially out of maintenance (at the earliest), in order to facilitate single-source porting to python3. That policy was adopted relatively recently, after the deprecation warning mentioning 3.6 was added in this issue, as I recall it.

    In this case we better resurrect getargspec(). Here's an issue for that: bpo-25486

    @1st1
    Copy link
    Member Author

    1st1 commented Oct 26, 2015

    This is the situation I am in: coverage.py uses getargspec in a very simple way in its tooling. I support 2.7 and 3.5, so I have to do this:

    try:
        getargspec = inspect.getfullargspec
    except AttributeError:
        getargspec = inspect.getargspec
    argspec = getargspec(function)
    

    I think it was me who submitted this code to coverage.py.. :) It might be worthwhile to keep it anyways, as getfullargspec uses the signature API, which supports a wider range of callables.

    @vedgar
    Copy link
    Mannequin

    vedgar mannequin commented Nov 19, 2015

    Also, it is worth noting, that Signature API does not provide 100%
    of functionality that deprecated APIs have. It is important to do
    a soft deprecation of outdated APIs in 3.5 to gather users feedback,
    and improve Signature object.

    Well, here is a feedback about lost functionality. inspect.getcallargs had a very nice property that it automatically bound the first argument to the instance of bound methods. It seems I have no general way to do it with Signature.bind. Of course I can put

    arguments['self'] = method.__self__
    

    afterwards, but theoretically, the argument doesn't have to be called 'self'. And anyway, I would like something that works seamlessly with bound methods and ordinary functions.

    @bitdancer
    Copy link
    Member

    bitdancer commented Nov 19, 2015

    Please open a new issue for that observation/request.

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Dec 1, 2016

    Noting for the record, as the general way of querying an unbound method for the name of the first parameter and adding it to the bound arguments:

        def add_instance_arg(callable, bound_args):
            try:
                self = callable.__self__
                func = callable.__func__
            except AttributeError:
                return # Not a bound method
            unbound_sig = inspect.signature(func)
            for name in unbound_sig.parameters:
                bound_args.arguments[name] = self
                break
    >>> method = C().method
    >>> sig = inspect.signature(method)
    >>> sig
    <Signature (arg)>
    >>> args = sig.bind(1)
    >>> args
    <BoundArguments (arg=1)>
    >>> add_instance_arg(method, args)
    >>> args
    <BoundArguments (arg=1, self=<__main__.C object at 0x7f07ab719668>)>

    @berkerpeksag
    Copy link
    Member

    berkerpeksag commented Feb 22, 2017

    New changeset 0899b98 by Berker Peksag in branch 'master':
    bpo-28814: Undeprecate inadvertently deprecated inspect functions. (#122)
    0899b98

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Mar 24, 2017

    New changeset 0246422 by Nick Coghlan (Berker Peksag) in branch '3.5':
    bpo-28814: Undeprecate inadvertently deprecated inspect functions. (#122) (#244)
    0246422

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Mar 24, 2017

    New changeset 2197eac by Nick Coghlan (Berker Peksag) in branch '3.6':
    bpo-28814: Undeprecate inadvertently deprecated inspect functions. (#122) (#243)
    2197eac

    @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

    8 participants