Incorrect showing of method/function parameters and 'docstring' information

[Episkiliski]

Environment data

• Language Server version: Pylance 2020.7.3
• OS and version: Windows 7 64bits
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.8.5 64-bit (conda)

Expected behaviour

for example, in Jupyter Lab:

Actual behaviour

Not showing the correct docstring and parameters information. I don't know if this is a problem related to Python extension or Pylance.

Logs

XXX

Code Snippet / Additional information

XXX

[jakebailey]

Pylance is a static analyzer, and can't get that information at runtime like Jupyter does (which has already executed the code and can access the real info).

In that first case, am I correct in saying that it's pandas? Our pandas stubs include the docstrings (as the "real" code produces them extremely dynamically), so it's possible some are missing.

As for open, that's #49.

[Episkiliski]

Thanks for the quick reply.
You are right, the first case is Pandas. I checked different pandas methods and none of them is shown properly (parameters are shown in an odd way and docstring is not shown):

[jakebailey]

Thanks. In all of those cases, you're in the "signature help" which is missing the docstrings in our stubs (and we apparently can't find it in the real implementation).

@huguesv will be able to look at this later.

Out of curiosity, what are you finding "odd" about the parameters?

[Episkiliski]

Sorry, I meant that it shows all the parameter options without a 'nice' format, which is what is nicely presented in a docstring. For me the best way to show parameters and docstring is the way that Jupyter Lab represents it (as per the screenshots shown in my first post).

[huguesv]

We'll need to reorganize our pandas stubs slightly to have the DataFrame class (among others) be in a relative location in the stub that matches the location in sources.

Right now, in stub we currently have DataFrame in pandas.core, but in sources it's in pandas.core.frame, so Pylance is not finding the class implementation in pandas.core.

Doing this should fix the tooltip, as well as go to definition.

[gramster]

So @huguesv in the next version the stubs will reflect the correct file layout but will still not show these docstrings, so they are likely cases where the docs are synthesized as part of pandas build.

[cpbotha]

I am running into this issue with Django as well.

PyLance is showing the docstring-less function signature from django-stubs (which it comes bundled with) instead of the docstring in the actual Django source code.

What I gather from #170 (comment) above is that PyLance should use type stubs for type info and source code for docstrings. However, with Django (for example) this is clearly not the case.

For django.db.models.ForeignKey, as one example, PyLance in VSCode shows only the signature on hover:

Although the source clearly has a docstring, and VSCode even offers to take me there with Go to definition:

Ideally hover would show the type information but also any docstring.

[jakebailey]

Sorry to give you the rigmarole, but I think the django thing is another thing entirely, either that hovers are missing docstrings or that there's a specific bug with django given it's finding the def.

This issue is about pandas docstrings being generated at runtime where the static analysis can't possibly put together what the docstrings going to be (e.g. they do something like read_csv.__doc__ = "...".format(...).

To save you from writing that all over again, I made #316. 🙂

[memeplex]

I'm not sure whether this is the same issue as the one described above but for builtin modules I also find the behavior of PyLance very inconvenient (vs Jedi). For example, this is the documentation popup for ArgumentParser:

It's badly formatted but that's not my point. As soon as I add parentheses it becomes:

Notice this is not the popup that is shown while I'm typing arguments but the documentation popup shown on hover (the mouse pointer being above ArgumentParser), that is in the same situation as before. I find it next to useless TBH.

[memeplex]

Oh, I guess mine is this one #316 (comment) instead.

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.