Is displaying docstrings from typestubs supposed to work?

[olejorgenb]

With my configuration, clicking on len("asdf") jumps to a typestub for len which has a docstring. Yet pyright only show the type info when I invoke quickdock on len.

Is this expected, or is there something I can configure?

It's notable that the typestub it jumps to does not include type information...

So maybe it's pycharm itself jumping (if pyright are not able to do the jump?) ("go to" -> "type declaration" does nothing)

[InSyncWithFoo]

This is PyCharm itself doing the go-to jump, with a PyCharm-bundled file as the destination.

I'm looking into PyCharm's log, and I'm actually unsure how/why Pyright doesn't get a request, even if the corresponding option is on. On VSCode, Pyright (as in the ms-pyright extension) jumps to a file somewhere in the directory containing the extension's distribution:

[Trace - 2:37:18 PM] Sending request 'textDocument/definition - (35)'.
Params: {
    "textDocument": {
        "uri": "file:///.../foo.py"
    },
    "position": {
        "line": 13,
        "character": 1
    }
}


[Trace - 2:37:18 PM] Received response 'textDocument/definition - (35)' in 8ms.
Result: [
    {
        "uri": "file:///.../.vscode-remote/extensions/ms-pyright.pyright-1.1.360/dist/typeshed-fallback/stdlib/builtins.pyi",
        "range": {
            "start": {
                "line": 1392,
                "character": 4
            },
            "end": {
                "line": 1392,
                "character": 7
            }
        }
    }
]

I'm sure the definition Pyright has in mind is this one, which is exactly the same as how the tooltip is displayed, no docstring:

def len(obj: Sized, /) -> int: ...

(Side note: Pylance seems to be able to directs len('') to str.__len__ instead of just the aforementioned generic len().)

For our executables, I would expect the destination to be somewhere inside ~/.cache/pyright-python/.

[InSyncWithFoo]

Converting to an issue: #29.

[olejorgenb]

According to this comment python/typeshed#4881 (comment) pylance jumps through some hops to get docstrings to work well :(

[InSyncWithFoo]

Upstream issue declined; the reason given is that this is a limitation and that the LSP API is meant to be a supplement, not replacement.

[olejorgenb]

Should be noted that PyCharm itself already fail to handle docs for at least certain type-stubbed libraries: https://youtrack.jetbrains.com/issue/PY-41716/Rendering-of-external-documentation-for-stdlib-doesnt-work-for-definitions-that-have-.pyi-stubs