python-lsp-server: Hover should not show docstring of inferred type but help for hover position

I agree, that this is more useful if no docstring is attached to the variable. However, if someone took the time to write a docstring for the variable I think it should be shown to the user.

Pyright for example shows both (result from a “textDocument/hover” request):

{
    "contents": {
        "kind": "markdown",
        "value": "```python\n(variable) bar: Literal[10]\n```\n---\nA variable named bar"
    },
    "range": [...]
}

Note that the variable docstrings are not a language feature but the format is generally accepted (Jedi, sphinx, Pyright, and probably more tools support it).

• Is BaseName#description the correct way to get the definition?

For me using BaseName#description looks more like a hack, because it shows the full line of code assigned to the variable, which looks more like Visual Studio’s approach when you hover a macro in C/C++.

• In which cases do we want to show the definition? Only for builtin types?

From what I see in pyright, the definition is shown when the value is literal, no matter if it’s a constant or variable. dict and list don’t show its contents.

Various pyright behavior

Same goes with constants.

• How should it be shown? Instead or next to the type information?

I think it will be effective enough to show it in order like ‘type, value (if applicable), docstring (if exists)’.

I believe this reasoning is incorrect, the intent of the definition request is not to present it in a hover but to enable go to/jump behaviour. It only returns a location object which does not have a field for text representation of the definition.

I see. That makes sense. So the question is more, if we really want to show a definition lookup in the hover result.

I started implementing variable definition lookup on hover because this is what pyright does.

I could be wrong, but I think the pyright results are types rather than definition lookups. I put some type inference into my PR but Jedi is less strict (does not use the type Literal[<val>] if a variable is constant).

---

If we decide on showing a definition lookup we should answer the following questions:

• Is BaseName#description the correct way to get the definition?
• In which cases do we want to show the definition? Only for builtin types?
• How should it be shown? Instead or next to the type information?

I am open to suggestions for enhancing my PR.

If this is done for builtins only, then it’s fine. I say it because trying to get values of objects using repr

I don’t do that via repr, but via description field of BaseName object.

Yes. Showing the value of a variable instead of the docstring of the built-in type is much more useful

If this is done for builtins only, then it’s fine. I say it because trying to get values of objects using repr is a bad idea since many libraries out there have buggy or not performant repr’s