Change idlelib.CallTips.get_argspec to use inspect.signature, new in 3.3, instead of inspect.getfullargspec and inspect.formatargspec. One thing it handles better is a namedtuple class, which has a C-coded __init__ inherited from object a Python-coded __new__ written by namedtuple. Signature() will also handle C-coded functions if and when Argument Clinic (new in 3.4) adds signature information.

from collections import namedtuple
from inspect import signature

Point = namedtuple('Point', 'x y')
print(signature(Point.__new__))
# '(_cls, x, y)'
print(signature(Point))
# '(x, y)'

Note that str (called by print) is needed to get the desired string form.

There are tests in CallTips.py, but they should be converted to unittest, moved to idle_test/test_calltips.py, changed to match new output detail, and expanded to include new examples.

*17481 is about changing getargspec to use signature, at least as a backup. But that would not fix the example here. The calltips have been moved in 20122.

I have not decided yet whether to apply to 3.4.

My understanding is that when a builtin is converted, a) the docstring signature disappears, and b) getfullargspec calls str(signature). I need to check what now happens with .getfullargspec version .signature for uncoverted builtins and if any changes should be made now.

.signature also handles wrapped functions better.

>>> def deco(f):
        import functools
        @functools.wraps(f)
        def ret(*args, **kw):
                return f(*args, **kw)
        return ret

>>> @deco
def f(n, k):
        return n + k*2

>>> import inspect as ip
>>> isf=ip.signature(f)
>>> print(isf)
(n, k)
>>> ip.formatargspec(*ip.getfullargspec(f))
'(*args, **kw)'

The above suggests that the change might be applied to 3.4. The difference surprises me because bpo-17481 patched getfullargspec() to 'use' signature() 'behind the scenes', so I expected the result to be the same. It seems that 'use' does not mean what I thought. My hesitation is that only some builtins have been converted to use Argument Clinic, and Idle currently treats builtins special to get the signature from the docstring. Treating just some builting special will be slightly awkward.

An example should make my concern clearer. str(signature(int)) is '()' because int (and all other builtins) has not been converted whereas the Idle calltip is
int(x=0) -> integer
int(x, base=10) -> integer
I do not want to simply add a line with '()' to the top of the calltip, so a little thought is needed to improve the calltip for the rare cases above without degrading them for existing, more common cases.

Several builtin functions have recently gotten the Arg clinic treatment. So I think it is now time to switch. Before closing bpo-29653 as a duplicate, I discovered that inspect.signature also handles functools.partials correctly, while the other inspect functions do not.

I'm now testing to change getfullargspect to signature. It came out that signature can't accept bound method with only _VAR_KEYWORD. This test case will gave a ValueError:

    >>> class C:
        def m2(**kw):
            pass
    >>> c = C()
    >>> ip.signature(c.m2)
   Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/inspect.py", line 3002, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "/usr/lib/python3.6/inspect.py", line 2752, in from_callable
    follow_wrapper_chains=follow_wrapped)
  File "/usr/lib/python3.6/inspect.py", line 2169, in _signature_from_callable
    return _signature_bound_method(sig)
  File "/usr/lib/python3.6/inspect.py", line 1759, in _signature_bound_method
    raise ValueError('invalid method signature')
ValueError: invalid method signature

Thanks for the report. As Yuri pointed out in msg292701, and I verified, c.m2() raises "TypeError: meth() takes 0 positional arguments but 1 was given".

The purpose of get_argspec is to tell the user how to call the function without getting such a TypeError. But this is not possible, at least in this case. When signature raises "ValueError: invalid method signature", get_argspec should catch ValueError and put, for instance, "Function has an invalid method signature" in the box, instead of a signature that does not work, so users will know that the function cannot be called properly. (Should message be red?)

An initial patch could just comment out this test. I would like to see whether everything else passes. Or have you, Louie, already done that?
Signature can raise "TypeError if that type of object is not supported". Does .signature return for all the other test cases? I expect it should if only called after current guard.

try:
    ob_call = ob.__call__
except BaseException:
    return argspec

Before committing a patch using .signature, the known possible exception (ValueError) must be caught. This test should then be changed to verify the new behavior.

Possible future enhancement. Current nothing happens after code like "1(" or "''(". Should a box pop up saying (in red?) something like "Non-callable object before ("?

Terry, only this case was failed, others in unittest work very well.

ah, there are still some corner case about _first_param.sub(), some of them in signature will be like (ci), not (self, ci), and the regex will replace the first params to (), which is not correct.

@terry, the PR is created, it is now serving with signature. The two exception (object not callable, invalid method signature) will return the corresponding message.

The only thing I didn't figure out it how to change the color, so I didn't test for this feature.

I will try to do that when I can.

Later today I should be able to pull the PR to my machine to review and test, and recheck coverage change.

I pulled your pr, did some minor edits, committed, and tried to push back following this line from the devguide Bootcamp page.

git push git@github.com:<contributor>/cpython <pr_XXX>:<branch_name>
--------------

F:\dev\cpython>git commit -m "Fix and stop repeating invalid signature message"
[pr_1382 bb46c06645] Fix and stop repeating invalid signature message
2 files changed, 6 insertions(+), 5 deletions(-)

F:\dev\cpython>git push git@github.com:lulouie/cpython pr_1382:pr_1382
The authenticity of host 'github.com (192.30.253.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added 'github.com,192.30.253.112' (RSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
-------------

Did I do something wrong or do you need to allow me to push?
https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/
############################################################

There current PR is incomplete. The main reason to switch to signature() is to get the signature of C-coded functions that have been converted to use Argument Clinic. But...

>>> import re
>>> import inspect as i
>>> str(i.signature(i.signature))
'(obj, *, follow_wrapped=True)'
>>> str(i.signature(re.sub))
'(pattern, repl, string, count=0, flags=0)'
>>> p = re.compile('')
>>> str(i.signature(p.sub))
'(repl, string, count=0)'
>>> p.sub(

After "i.signature(" and "re.sub(" (both 'function's), the popup has the signature. After p.sub (a 'builtin_function_or_method'), there is only the beginning of the doc string, as before. Signature is not called because of the current guard. It must be removed.

Returning _invalid_signature (defined in my patch) on ValueError should only be done when the message is 'invalid method signature'. (Can there be an invalid function signature that compiles? In not, removing 'method' (in my patch) is a mistake). signature(int) raises "no signature found for builtin type <class 'int'>". In such cases, argspec should be left as '', to be augmented by the docstring as now.

Tests need to include some builtins that have been converted. Serhiy, can you suggest a suitable module with converted functions and class methods? Any of the builtins?

Did I do something wrong or do you need to allow me to push?

Yes, I've added you to the collaborators on my fork (lulouie/cpython).

But in fact, new GitHub workflow will need to do something different, not just edit-and-commit. You will need to go to PR 1382 (#1382) and start a new review. Click "file changes", when your cursor hovers on the source code line, it will pop out a blue plus icon on the line number, then click it to add a new comment on it, after that, click "start review" and do the rest comment.

After comment finish (maybe multiple lines), the top nav bar has a green button "Review changes" with total comment count, click it and add the summary comment for this review, and choose this is a comment, approve, or requests changes. In this case, you will choose requests changes for it. Also, Python member's requests changes will block the merge process, until all requests changes were approval.

In summary, in GitHub workflow, code review will be like a request, and the main committer stays for who create this PR, not reviewers.

A review is not required to commit. The PR itself says "Add more commits by pushing to the bpo-19903 branch on lulouie/cpython." As far as I know, unresolved requests do not block for cpython. The Merge button appears to still be 'alive' after my red review.

I have done reviews on other issues, both + and -, with comments on individual lines. I like it best when there is only a single commit at the time of review. Otherwise, I don't see any way to comment on the total change after multiple unsquashed commits. I also don't like commenting on an obsolete line or searching through multiple commits to find the last that touched a line.

I accepted your invitation over 1/2 hour ago and got confirmation from github. But pushing with this revised command
git push git@github.com:lulouie/cpython pr_1382:bpo-19903
still fails, with the same message.

Thing just getting weird. If we remove the guard, some of the builtin function will get not-so-good signature result:

>>> i.signature(range.__init__)
<Signature (self, /, *args, **kwargs)>
>>> i.signature(list.append)                                                                                          
<Signature (self, object, /)>
>>> i.signature([].append)                                                                                            
<Signature (object, /)>

You can check my latest commit, The most big change is about __method__, it will make some different behavior:

str(i.signature(list.__new__)) -> (*args, **kwargs)
str(i.signature(p.sub)) -> (repl, string, count=0)

both of them are BuiltinFunctionType, and the first one in old version will be guard, so the get_argspec result will be docstring, we can't different them in non-guard version.

Let's back up. The high-level specification for get_argspec is something like 'Return information that will help programmers write a correct call." The proposed implementation strategy is to combine signature info from signature (replacing getfullargspec) and the initial part of the callable docstring.

This goal and strategy mimic help(callable). So we can use its output as a guide, but improve on it when we can and think we should. This issue could be framed as 'catch up with help(callable)' which already switched to signature.

The test examples constitute a low-level specification by example. As such, they should be discussed here before changing the code. Let's consider the ones you listed, using 'help(callable)' as a guide.

>>> help(range.__init__)
Help on wrapper_descriptor:
__init__(self, /, *args, **kwargs)
    Initialize self.  See help(type(self)) for accurate signature.

Not very helpful, but if one types 'range.__init__(', one currently sees the last line and should see the last two lines in the future.

However, the calltip for 'range(' should not be the above. When type(init).__name__ == 'wrapper_descripter, the "fob = ob.__init__" replacement should not happen, at least not until we see a case where a wrapper_descripter has the real signature. (Whether is it still needed for python-coded classes is a separate issue.) I don't know if all built-in inits

>>> help(list.append)
Help on method_descriptor:
append(self, object, /)
    Append object to the end of the list.
>>> help([].append)
Help on built-in function append:
append(object, /) method of builtins.list instance
    Append object to the end of the list.

The signature output is fine with me. I want future calltips to include it, along with the docstring line.

The only issue is the ', /'. If people can survive it presence in help output, ditto for calltips. But whenever a signature string contains '/', we could add, between signature and docstring lines, the following.
"('/' marks preceding arguments as positional-only.)" If we do this, the string should be a global '_positional = ...' so it can be used as-is for tests. I am inclined to try this.

I want to leave the '/' in the signature because there have been multiple issues and forum questions about why the equivalent of [].append(object='a') does not work. Now, some built-in parameters are positional-only, some keyword-only, and some both. The hint should make this clear.

>>> help(list.__new__)
Help on built-in function __new__:

__new__(*args, **kwargs) method of builtins.type instance
Create and return a new object. See help(type) for accurate signature.

'list.__new__(' currently pops up just the docstring. I think adding (*args, **kwargs) on top of it does not hurt and maybe is a slight improvement, as it explains the second line a bit. In any case, explicitly calling __new__ and __init__ is extremely rare, especially for beginners.

For rexep.sub, adding (repl, string, count=0) on top of "Return the string obtained by replacing the leftmost non-overlapping occurrences o..." is a pure win. Wrapping the too-long docstring line is a separate matter.

list.__new__ is inherited from object. Look at list.__init__.

help(object.__init__) and help(list.__init__) have exactly the same output.

Ah, yes, __new__ and __init__ differ from ordinal methods. They don't have docstrings generated by Argument Clinic. But list itself as a callable have correct signature.

>>> inspect.signature(list)
<Signature (iterable=(), /)>

(I presume'ordinal' meant 'ordinary'.) I don't know where signature finds the info on built-in type objects Methods like .append have .__text_signature__. List does not, and list.__call__.__text_signature is the generic '($self, /, *args, **kwargs)'. That signature finds it somewhere is a reason for the switch. There is no longer a signature in the first lines of the docstring. So currently, 'list(' only displays "Built-in mutable sequence."

Louie, I verified that for python-coded classes, signature itself gets the info from the __init__ method, so we don't need 'fob = ob.__init__' for python classes either.

>>> list.__text_signature__
'(iterable=(), /)'

But IDLE shouldn't use __text_signature__ directly, it should use the inspect module.

Interesting dir(list.append) and the IDLE completion box show __text_signature__. dir(list) and the box do not.

As well as __name__, __qualname__, __module__, __bases__, __call__, mro, etc.

But somehow in this case, List have no __text_signature__:

>>> str(i.signature(list))
'(iterable=(), /)'
>>> list.__text_signature__
'(iterable=(), /)'
>>> str(i.signature(List))
'(iterable=(), /)'
>>> List.__text_signature__
>>>

And, another case, the __text_signature__ and i.signature() is similar, but not the same:

>>> range.__init__.__text_signature__
'($self, /, *args, **kwargs)'
  ^
>>> str(i.signature(range.__init__))
'(self, /, *args, **kwargs)'

So we can't simply compare-and-eliminate this case.

What is List? Not a builtin.

I am guessing that $self means to remove for bound methods. In any case, __text_signature__ is effectively private to inspect.signature. We only care what the latter produces.

Am I right in assuming this will also fix the bug mentioned in this comment

https://emptysqua.re/blog/copying-a-python-functions-signature/#comment-1816090904

? If yes, I'm glad I didn't have to report it. :-)

New changeset 646f6c3 by Terry Jan Reedy in branch '3.6':
[3.6] bpo-19903: IDLE: Calltips changed to use inspect.signature (GH-2822) (bpo-3053)
646f6c3

Although my freshly opened window says PR2822 is open, it was merged with
3b0f620
4 hours ago, and then backported. Louie, thanks for the patch and the persistence.

This issue is about IDLE getting further out of the business of calculating signatures and depending instead on the newest (and tested) inspect function.

In 2012, the blogger used getargspec, which was deprecated for 3.x a few years before, in 3.0. I suspect that the blog is about 2.x, which is no longer relevant for IDLE development.

Inspect.getargspec was superceded by getfullargspec, which was superceded by signature. Read more at
https://docs.python.org/3/library/inspect.html#inspect.getfullargspec
https://docs.python.org/3/library/inspect.html#introspecting-callables-with-the-signature-object

Signature() has a keyword-only option follow_wrapped=True. The new patch uses this default. I suspect that this is relevant to the blogger's concern, but I don't know which value the blogger would want. Either way, I would not switch unless convinced that False is the best choice for beginning users. Any such discussion would be a new issue.

Hm... now I see that link is very misleading... it opens a blog post, and then only a few seconds later jumps to the comment. So now I'll paste the comment here, to avoid misunderstandings:

Python3.6.0 (now in 2017). I start IDLE, and write

>>> def deco(f):
        import functools
        @functools.wraps(f)
        def ret(*args, **kw):
                return f(*args, **kw)
        return ret

>>> @deco
def f(n, k):
        return n + k*2

>> f(

And get a tooltip (*args, **kw) instead of (n, k). I guess this is a bug.

This is much clearer. What you got is a limitation of getfullargspec relative to signature (see the links). In this case, you want follow_wrapped=True, to get the specific signature of the wrapped function instead of the generic signature of the wrapper*. With the patch, the tip in 3.6 and 3.7 is '(n, k)'. So yes, this is one of the changes consequent on the switch.

>>> str(inspect.signature(f,follow_wrapped=False))
'(*args, **kw)'