inspect: Deprecate getfullargspec?

@brettcannon

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']

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".

I vote deprecation with no stated plans of removal

Although I say do it in 3.5.

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

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

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={})

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.

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)?

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

you deprecate in the doc for 3.5?
you deprecate in the code for 3.6?
you remove the code in 3.7?

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

Thanks

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.

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?

I'd +1 for:

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

Brett?

Brett,

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

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.

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.

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

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?

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.

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.

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.

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

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.

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.

Please open a new issue for that observation/request.

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>)>

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

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

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

Navigation Menu

Repository navigation

inspect: Deprecate getfullargspec? #64637

13 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

inspect: Deprecate getfullargspec? #64637

Description

Activity

1st1 commented on Jan 29, 2014

brettcannon commented on Jan 29, 2014

brettcannon commented on Jan 29, 2014

ncoghlan commented on Jan 29, 2014

matrixise commented on Apr 15, 2014

matrixise commented on Apr 15, 2014

brettcannon commented on Apr 15, 2014

1st1 commented on Apr 15, 2014

matrixise commented on Apr 15, 2014

brettcannon commented on Apr 15, 2014

matrixise commented on Apr 15, 2014

1st1 commented on Apr 15, 2014

matrixise commented on Apr 15, 2014

brettcannon commented on Apr 15, 2014

13 remaining items

untitaker commented on Sep 15, 2015

untitaker commented on Sep 15, 2015

nedbat commented on Oct 25, 2015

1st1 commented on Oct 25, 2015

bitdancer commented on Oct 26, 2015

nedbat commented on Oct 26, 2015

1st1 commented on Oct 26, 2015

1st1 commented on Oct 26, 2015

vedgar commented on Nov 19, 2015

bitdancer commented on Nov 19, 2015

ncoghlan commented on Dec 1, 2016

berkerpeksag commented on Feb 22, 2017

ncoghlan commented on Mar 24, 2017

ncoghlan commented on Mar 24, 2017

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions