Revision e4598364ea29 changed the docstring for "int", causing the CallTips test to fail in IDLE.

The attached patch fixes the problem.

Yes, I also noticed this. However, "int(x=0) -> integer" is not enough. The right calltip should be "int(x=0) -> integer\nint(x, base=10) -> integer".

Here is a patch, which adds multiline calltips support.

Here is a patch, which adds multiline calltips support.

Serhiy, it looks like this issue/patch is just to fix the test and not to add "support." Also, it looks like the test only checks the first line, so that the second line shouldn't be added to the expected value. For example, the code comment for test_builtins() says:

# if first line of a possibly multiline compiled docstring changes,
# must change corresponding test string

Sorry, I see that you changed the logic of get_argspec(). In that case, you should probably update the docstring of get_argspec() as well as the code comment I referenced (so that both say which lines are checked rather than the first line).

Done. Here is an updated patch.

The number of lines in the return value of get_argspec should be limited, otherwise the calltip window can become too large. For example, many functions in the numpy project have very long doc strings.

I would separate the issue of fixing the test (behavior) from adding support for multi-line tool tips (enhancement). Unless the policy for IDLE is different, it seems the latter should be limited to 3.4.

The number of lines in the return value of get_argspec should be limited, otherwise the calltip window can become too large.

Calltip limited by first empty line. But I agree, some reasonable hard limit (say 10 lines) should be.

I would separate the issue of fixing the test (behavior) from adding support for multi-line tool tips (enhancement).

Then calltip will be wrong. int can accept two arguments, not only one. Alternative consistent solution is to revert all changes which were convert oneline signatures to multiline (I think you won't like this ;) ).

Unless the policy for IDLE is different, it seems the latter should be limited to 3.4.

The policy for IDLE is different.

Patch updated. Added hard limit (10) for number of calltip lines.

I don't think it was ever a requirement of docstrings that their signature fit on one line or that they render fully in IDLE. Other built-in functions have multi-line signatures going back 10+ years (e.g. 32e7d0898eab).

I still think that the rendering of multi-line signatures should be considered separately. The discussion and issues are different, and people may have different opinions. For example, why not be smarter about detecting the end of the signature (e.g. first line not having "->")? Would you object to creating a new issue?

I don't think it was ever a requirement of docstrings that their signature fit on one line or that they render fully in IDLE.

I think this is a requirement of IDLE.

I still think that the rendering of multi-line signatures should be considered separately. The discussion and issues are different, and people may have different opinions.

Then what about this issue? Legalize the current invalid behavior in the tests? I think that the tests should check the valid behavior and if tests failed then the behavior should be corrected, not tests should be faked.

For example, why not be smarter about detecting the end of the signature (e.g. first line not having "->")?

This is a reasonable proposal. Let's discuss it.

The objection is that there are such signatures:

foo(a, b, c,
    e, f, g) -> some result

Would you object to creating a new issue?

There is no difference for me what issue it will be, but if it will be a different issue, then I do not see any sense in this issue.

I created bpo-16638 to add support for multi-line signatures.

Then what about this issue?

This issue is to fix the failing test. The test that is failing is to check that fetch_tip correctly returns the first line of a built-in's docstring and that it handles inheritance correctly, etc. Its purpose is not to check that the docstrings are written a certain way. Otherwise, for example, it would be checking all built-ins rather than just choosing one example.

So, is the original patch which fixes the original issue OK to apply?

Yes, I think so. I should be able to get to it in the next few days unless someone else beats me to it.

FYI, in the 3.2 branch I get 4 failures rather than just the one due to int:

$ ./python.exe Lib/idlelib/CallTips.py
int - expected
'int(x[, base]) -> integer'
 - but got
'int(x=0) -> integer'
list.append - expected
'L.append(object) -> None -- append object to end'
 - but got
'L.append(object) -- append object to end'
[].append - expected
'L.append(object) -> None -- append object to end'
 - but got
'L.append(object) -- append object to end'
List.append - expected
'L.append(object) -> None -- append object to end'
 - but got
'L.append(object) -- append object to end'
4 of 41 tests failed

Also, what is the recommended way to run IDLE tests? It doesn't seem to be a part of regrtest, and I didn't see this information in the devguide.

New changeset 181c170c6270 by Chris Jerdonek in branch '3.2':
Issue bpo-16629: Fix IDLE idlelib.CallTips test. Patch by Roger Serwy.
http://hg.python.org/cpython/rev/181c170c6270

New changeset 5182cc18b7b4 by Chris Jerdonek in branch '3.3':
Issue bpo-16629: Merge IDLE test fix from 3.2.
http://hg.python.org/cpython/rev/5182cc18b7b4

New changeset db17a49395c2 by Chris Jerdonek in branch 'default':
Issue bpo-16629: Merge IDLE test fix from 3.3.
http://hg.python.org/cpython/rev/db17a49395c2

Thanks a lot, Roger!

I created bpo-16655 for the three test failures I observed above.

@chris: Thanks for applying the patch. As for IDLE tests, there are no official tests. bpo-15392 calls for the creation of a unit test framework. There are a few "tests" in some of IDLE, such as the ones in CallTips. Terry added much needed improvement for those tests in bpo-12510.

I will look at these issues with 3.2 as soon as I get a chance.