[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Change by Nick Coghlan :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Change by Nick Coghlan :


--
assignee: ncoghlan -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan  added the comment:

Independently of what we eventually decide to do for 4.0, there are some 
changes we could make at the documentation level to more clearly indicate "Even 
though this isn't deprecated, you still shouldn't use it for new code": 
https://bugs.python.org/issue32190

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Brett Cannon]

Brett Cannon  added the comment:

I'm not saying we remove getfullargspec() **right now**, just that we don't 
keep it around long-term as it simply can't evolve to keep up with how rich our 
parameter support is today and might become in the future. And that's why, for 
me, the deprecation was enough to signal, "this code is here for now and you 
can use it, but you really need to be aware of some issues that are leading to 
it being removed". Now obviously you prefer the doc approach for this, Nick, 
and that's fine since this is quickly devolving into "agree to disagree" as 
while "there are plenty of other standard library APIs that we keep around 
primarily for backwards compatibility reasons", I personally would say we 
should be prepared to deprecate them for Python 4 (which is what I'm talking 
about here, not e.g. 3.8).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan  added the comment:

I'll also note that one possible alternative would be to accept Ryan's original 
proposal, which was to make "skip_bound_arg=False" part of the public API for 
`inspect.Signature.from_callable`.

Keeping `getfullargspec` around (but discouraged for new code), seems nicer to 
me than doing that, though, since the *only* use case we're aware of for that 
behaviour toggle is to be able to emulate inspect.getfullargspec() atop 
inspect.Signature().

TOOWTDI simply doesn't strike me as a good enough reason to break working code 
in this case - there *is* an obvious way for new code (inspect.signature), and 
there are plenty of other standard library APIs that we keep around primarily 
for backwards compatibility reasons, even though we don't necessarily recommend 
using them any more.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan  added the comment:

If there was a documented deprecation that said "Use  
instead", I'd be OK with that.

The part I wasn't OK with is multiple projects each copying & pasting their own 
variant of the getfullargspec code and accessing private inspect module APIs in 
order to get the old behaviour back.

So in order to move this to PyPI instead, we'd need to offer a completely 
public API that was equivalent to `_signature_from_callable(func, 
follow_wrapper_chains=False, skip_bound_arg=False, sigcls=Signature)`

`inspect.Signature.from_callable(func, follow_wrapped=False)` comes very close, 
but misses a subtlety where "getfullargspec" will mention "self" for bound 
methods, even though it's implicitly supplied, and doesn't need to be supplied 
by the caller.

That aspect could potentially just be deprecated outright though, with the PyPI 
replacement following inspect.signature's behaviour and reporting the actual 
call signature of the bound method.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Brett Cannon]

Brett Cannon  added the comment:

Nick pointed me at this issue for the undeprecation of 
inspect.getfullargspec(). While I'm fine with the un-deprecation for 
compatibility reasons, I would rather the function not last beyond Python 3 
un-deprecated. Nick says, though that:
"""
... the undeprecation
isn't a Python 2/3 issue, it's a "tuples, lists and dicts are really
handy representations of things, and Python developers often prefer
them to more structured objects" issue.

The modern inspect.getfullargspec implementation is a relatively thin
wrapper around inspect.signature, and the only lossy part of the
output transformation is that you can't tell the difference between
positional-only and positional-or-keyword parameters.
"""

My argument is TOOWDI and as of right now there's 3 for getting parameter 
information for functions (of which only one is currently deprecated). I would 
also argue that if people want a "signature to core data structure" translation 
then that can be covered by a package on PyPI since even now getfullargspec() 
is lossy and we don't need that kind of pragmatic support in the stdlib for 
this.

--
nosy: +brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan  added the comment:

Note: the minor incompatibility that required getfullargspec() to be a separate 
API in the first place is the fact that it returns a 7 element named tuple 
instead of a 4 element one.

This means that hybrid 2/3 code needs to consistently use name based item 
access rather than tuple unpacking, but other than that, all code related to 
the first four fields can be identical across versions. (Code related to 
handling the extra three fields will naturally only be needed on 3.x)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan  added the comment:

Larry, your personal insult is entirely unwelcome, unnecessary, and 
unappreciated, especially as it's wrong regarding the Python 2/3 compatibility 
concerns.

While getfullargspec() is indeed new in Python 3.x, it's also deliberately 
designed as a *drop-in replacement* for inspect.getargspec(). This means 
straddling Python 2 & 3 is straightforward, since you just need to toggle which 
API function you call (getargspec() on 2.7, getfullargspec() on 3.x).

This is *not* the case for switching to the inspect.signature() API: doing that 
for existing code that still supports Python 2.7 also requires switching to one 
of the third party backports of that API to 2.7, and then changing the way your 
own code models function signatures.

This is why getfullargspec() only received a documented deprecation, rather 
than a programmatic one. However, the combination of that notice in the 
documentation with the programmatic deprecation warning in getargspec() was 
enough to make people believe that in order to add Python 3 support, they 
*also* had to either switch to the inspect.signature() API, or else write and 
maintain their own version of getfullargspec().

That wasn't the intended outcome, and we have no plans to actually remove 
getfullargspec(), so I changed the wording in the getargspec() deprecation 
warning and the getfullargspec() documentation to better encourage the desired 
behaviour (i.e. inspect.signature() being used in new code, and existing code 
being migrated to the inspect.signature() API as developers find value in doing 
so)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Tim Graham]

Tim Graham  added the comment:

Perhaps the reason for the undeprecation could use some clarification. In a 
Python 3 only world (where Django's master branch is), I believe there's still 
usefulness for inspect.getfullargspec() -- see 
https://github.com/django/django/search?q=getfullargspec for usages.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Larry Hastings]

Larry Hastings  added the comment:

Wait, what is all this nonsense?

inspect.getfullargspec is Python 3 only.  It was added to support keyword-only 
parameters.  Python 2 doesn't *have* keyword-only parameters, so it isn't 
needed there.

Check for yourself: Python 2 doesn't have inspect.getfullargspec.

https://docs.python.org/2/library/inspect.html#inspect.getargspec

We might consider un-deprecating inspect.getargspec() for supporting code 
supporting Py2 and Py3.  But there's no point in un-deprecating 
inspect.getfullargspec() for that reason.

Nick: please *back out* your pointless, taffy-headed checkin.

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan  added the comment:

Oops, we/I missed the window for also getting the deprecation removed from 
3.5.x (as that branch is now in security-fix only mode).

Marking as resolved for 3.6 accordingly.

--
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan added the comment:

Also, note that the programmatic deprecation warning change in the patch is to 
the warning for `getargspec()`, so that it recommends `getfullargspec()` rather 
than `Signature()`.

There's no runtime deprecation warning for `getfullargspec()` in any version of 
Python 3.x, so projects can use it freely, regardless of target version.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan added the comment:

No, there are no plans to ever deprecate getfullargspec() again - it isn't hard 
to maintain indefinitely as a wrapper around inspect.Signature(), and it 
doesn't have the significant limitations that affected getargspec().

--
priority: deferred blocker -> normal
stage: needs patch -> backport needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Tim Graham]

Tim Graham added the comment:

Does it seems likely that getfullargspec() will be deprecated after Python 2 is 
EOL? Django is currently reimplementing getargspec():
https://github.com/django/django/blob/8ab7ce8558792f41637d6f87f2a8a117e169dd18/django/utils/inspect.py#L4-L24

A pull request proposes to modify that implementation to behave as 
getfullargspec(): https://github.com/django/django/pull/8410

Django master now supports Python 3.4+, so I guess we would rather use 
getfullargspec() if it's not going to be deprecated in the future. The only 
downside is that it would introduce deprecation warnings for Python 3.5 users 
since those warnings haven't been removed yet. I guess Django could silence 
them.

--
nosy: +Tim.Graham

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests:  -923

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Donald Stufft]

Changes by Donald Stufft :


--
pull_requests: +923

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan added the comment:

Thank you Serhiy!

That leaves this just as a pending update for 3.5.3 to bring it into line with 
3.6.0.

I've reverted the stage to "needs patch" and removed the patch keyword, as the 
3.5 patch will be slightly different:

- using 3.5.3 in the versionchanged notice
- adjusting the 3.5 What's New to change the list of deprecated inspect module 
APIs

--
stage: commit review -> needs patch
versions:  -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Ned Deily]

Ned Deily added the comment:

It looks like Serhiy took care of the merge to default in dd4c420b8e66.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan added the comment:

I've pushed the change for 3.6.0rc1 based on Yury and Martin's review, but 
wasn't able to forward merge it to default due to merge conflicts on Misc/NEWS 
that I wasn't sure how to resolve.

--
priority: release blocker -> deferred blocker
stage: needs patch -> commit review
versions:  -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 14c2d93ffcb3 by Nick Coghlan in branch '3.6':
Issue #27172: Undeprecate inspect.getfullargspec()
https://hg.python.org/cpython/rev/14c2d93ffcb3

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan added the comment:

Updated patch adding What's New and NEWS entries, and addressing Martin's 
review comments (mostly by accepting his suggestions).

I ended up leaving `inspect.getcallargs()` deprecated, and instead added a 
comment to issue 20438 noting how to achieve the bound args -> unbound args 
conversion in a general way: http://bugs.python.org/issue20438#msg282173

--
Added file: 
http://bugs.python.org/file45723/issue27172_undeprecate_getfullargspec_v2.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Yury Selivanov]

Yury Selivanov added the comment:

Nick, your patch LGTM.  I'd only add to the getargspec section that 
getfullargspec is usually a drop-in replacement (I've yet to see code where 
it's not the case).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan added the comment:

Initial patch attached. Key missing pieces:

- needs a What's New note
- needs to undeprecate inspect.getcallargs() as well (more on that below)

As my last couple of comments indicate, I'd forgotten that only getargspec() 
was programmatically deprecated, which means the sole code change is a 
rewording of the getargspec() warning to mention both signature() and 
getfullargspec().

The documentation changes are a bit more extensive, as I couldn't resist fixing 
the longstanding terminology error in the docs and docstrings, where these 
functions are mostly reporting *parameter* names, not argument names (callable 
arguments have values, not names).

I think the "versionchanged" note works well for indicating that folks aren't 
imagining things if they remembered seeing this function marked as deprecated.

However, I also went back and checked the 3.5 What's New, and that does mention 
the deprecations, so I'll need to do another version of this patch that 
includes a 3.6 What's New notice retracting those deprecations.

That check also reveals some other documented deprecations that should probably 
be reverted.

Firstly, getargvalues() and formatargvalues() are *frame* introspection 
functions, and hence have nothing whatsoever to do with inspect.signature(). 
The code and docs are just a bit confusing as they're interleaved with the 
callable introspection functions. I've filed that as a new issue: 
http://bugs.python.org/issue28814

Secondly, https://bugs.python.org/issue20438#msg254892 notes that 
inspect.getcallargs() has some behaviours that differ from Signature.bind in a 
way that's a bit of a pain to replicate on top of the latter. Similar to 
getfullargspec(), what do folks think of the idea of reverting that deprecation 
at least until 2.7 goes EOL?

(Noting for the record so folks don't wonder if it's an accidental oversight: I 
think formatargspec should retain its documented deprecation, as folks really 
are better off writing their own formatting function based on the data returned 
or switching to the new signature API)

--
keywords: +patch
Added file: 
http://bugs.python.org/file45663/issue27172_undeprecate_getfullargspec.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Ned Deily]

Ned Deily added the comment:

Nick, that seems like the right thing to do.  Thanks for following up on it.

--
nosy: +larry
priority: normal -> release blocker
versions: +Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan added the comment:

When we undeprecate this, we should remove and reword the deprecation warnings 
in the next 3.5 maintenance release as well.

I'll need to decide on a way to indicate in the docs that some versions of 
3.x.y will report a deprecation warning for getfullargspec() though - probably 
a "Changed in" note.

--
versions: +Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan added the comment:

This just came up in a discussion on a urllib3 patch, so I'd like to fix it for 
3.6.0rc1.

Ned, given that the code change here is just deleting the deprecation warning 
from getfullargspec() and rewording the one for getargspec(), does that seem OK 
for 3.6.0?

--
assignee:  -> ncoghlan
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[R. David Murray]

R. David Murray added the comment:

Also, this is now a documentation issue, though it does require a code change 
for the getargspec deprecation message.

--
assignee: yselivanov -> 
components: +Documentation -Library (Lib)
keywords:  -patch
type: enhancement -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[R. David Murray]

R. David Murray added the comment:

The existing patch no longer addresses the revised decision about the API (or 
the new title of the issue).  So, we need a new patch.

--
nosy: +r.david.murray
stage: commit review -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27172] Undeprecate inspect.getfullargspec()

[Nick Coghlan]

Nick Coghlan added the comment:

OK, as per the above discussion, I've changed the title of this issue to be to 
undeprecate inspect.getfullargspec().

That change involves two pieces:

- change the documented deprecation of inspect.getfullargspec() to instead be a 
recommendation to avoid using it in new code, and instead use 
inspect.signature()
- update the inspect.getargspec() documentation and programmatic deprecation 
warning to point to both inspect.signature() and inspect.getfullargspec() as 
potential replacements

That gives folks already using inspect.getfullargspec assurance that it isn't 
going away anytime soon (if ever), while folks using inspect.getargspec get a 
lower impact migration path to a more Python 3 friendly version of the callable 
introspection API.

--
title: Add skip_bound_arg argument to inspect.Signature.from_callable() -> 
Undeprecate inspect.getfullargspec()

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com