2

If I import the requests Python library (for example) and hover over requests.get I see this:

enter image description here

See how the function signature parameters and types are described in detail? Now, if I Ctrl+Click on the get method, I am taken to my local <python-dir>/site-packages/requests/api.py file where the function is exported. If I hover over the get function there I see the following much less descriptive function signature:

enter image description here

I also don't see any type annotations there either, so the question is, where is all that other type information for the function signature coming from when I hover over it in my own script, and how do I add similar information for my own code?

Aaron Beaudoin
  • 461
  • 1
  • 5
  • 14
  • It's called documentation aka [docstring](https://peps.python.org/pep-0257/) in python. As for the format to choose, I think [this question](https://stackoverflow.com/questions/3898572/what-are-the-most-common-python-docstring-formats) has enough answers for that. As for the _type_ information, that's just [type annotations/hints](https://peps.python.org/pep-0484/) which were introduced in python 3.5 – smac89 Jun 14 '22 at 16:36
  • This is not at all what is being asked in my question. I know what a docstring is, and I know what type annotations are. If you look at the screenshots, you'll see that the `requests.get` source has neither type annotations nor any type information in the docstring (except for the return type). So the question is therefore, in the first screenshot, why is there type information in the function signature in the IntelliSense popup? Where is that information coming from, when it doesn't appear to be anywhere in the source code in the second screenshot? – Aaron Beaudoin Jun 14 '22 at 16:49
  • I can't really answer why it doesn't give as much information for the local function signatures, but I think your main question is about Pylance https://visualstudiomagazine.com/articles/2021/05/11/vscode-python-may21.aspx – jonsca Jun 14 '22 at 16:59
  • @jonsca I think you may be right. The language server seems to be adding extra information – smac89 Jun 14 '22 at 17:09
  • 2
    Added a [question](https://github.com/microsoft/pylance-release/issues/2928) over on the Pylance repository on GitHub. I'll answer the question here on StackOverflow if I get a response. – Aaron Beaudoin Jun 14 '22 at 17:16

1 Answers1

2

This is clearly explained in type stub files.

Why does Pyright not attempt (by default) to determine types from imported python sources? There are several reasons.

  1. Imported libraries can be quite large, so analyzing them can require significant time and computation.
  2. Some libraries are thin shims on top of native (C++) libraries. Little or no type information would be inferable in these cases.
  3. Some libraries override Python’s default loader logic. Static analysis is not possible in these cases.
  4. Type information inferred from source files is often of low value because many types cannot be inferred correctly. Even if concrete types can be inferred, generic type definitions cannot.
  5. Type analysis would expose all symbols from an imported module, even those that are not meant to be exposed by the author. Unlike many other languages, Python offers no way of differentiating between a symbol that is meant to be exported and one that isn’t.
Gino Mempin
  • 25,369
  • 29
  • 96
  • 135
MingJie-MSFT
  • 5,569
  • 1
  • 2
  • 13
  • This is the answer. As explained in the question on GitHub [here](https://github.com/microsoft/pylance-release/issues/2928#issuecomment-1155489425), you can see where this extra type information is coming from by right-clicking the method name and selecting _**Go to Declaration**_ instead of _**Go to Definition**_. For the `requests` library, and many others that don't provide built-in type information, this information is coming from an external source called [`typeshed`](https://github.com/python/typeshed). – Aaron Beaudoin Jun 15 '22 at 13:51