Tooltip doesn't show constructor docstrings

[fperez]

Hey @Carreau, try this one in a notebook:

from IPython.core.display import Image
Image(<TAB HERE>

You get a 'no docstring', while doing Image? works. The reason is that in ?, we check if the object has no docstring but is a class, and in that case we display its constructor docstring, which is typically the most useful one. In fact, for classes that have both, we show both. Futhermore, for classes the signature that matters is the constructor one, since that's what people will actually be calling:

In [1]: class X:
   ...:     """class ds"""
   ...:     def __init__(self):
   ...:         "instance ds"
   ...:         

In [2]: 

In [2]: X?
Type:       classobj
String Form:__main__.X
Namespace:  Interactive
Docstring:  class ds
Constructor information:
 Definition:X(self)
 Docstring:     instance ds

Ideally, the tooltip would have the same semantics (not show the rest of what ? shows, but do the same regarding docstrings and call signatures).

I don't know how much time you have over the next few days (and you've already done great work!) but it would be great to ship the notebook with this in really solid shape.

[Carreau]

@bfroehle
I see that you've been faster than me, you might want to Initialize defstring with reply.call_def (I suppose this mean call_definition) to be coherent with the docstring logic .

@fperez sayed :

>  In fact, for classes that have both, we show both

So we might also want to append the differents *_docstrings maybe...

[bfroehle]

For symmetry with qtconsole, etc, I guess we should reimplement IPython.core.oinspect.call_tip (and whatever it calls) in Javascript.

[bfroehle]

In the Qtconsole we do NOT show both docstrings, only the one with the highest priority:

    # Now get docstring.
    # The priority is: call docstring, constructor docstring, main one.
    doc = oinfo.get('call_docstring')
    if doc is None:
        doc = oinfo.get('init_docstring')
    if doc is None:
        doc = oinfo.get('docstring','')

[fperez]

As mentioned when closing #1096, eventually a nice refactoring of these tools for better reuse and uniformity in output is needed.