Go To Definition jumps to source rather than typeshed stubs

[tekumara]

"Go to Definition" on stdlib functions jumps to the module source rather than the typeshed stubs.

The behaviour of the default python extension ie: without pyright, is to jump to the module source.

This is also the behaviour in PyCharm.

[erictraut]

If you have both a type stub (including those that ship as part of typeshed) and a library implementation is present, Pyright will show you the definition in both locations, and you can choose between them. For example, see this screen shot.

[tekumara]

It defaults to the type stub, is there a way to default to the more useful source instead? (or even better, ignore the type stub altogether)

[tekumara]

Duplicate microsoft/pylance-release#65

[erictraut]

I'm not sure what you mean by "it defaults to the type stub". You should see both options appear, as in the screen shot above. It doesn't default to one or the other.

Both the type stub and the source contain valuable information depending on your objective. From a type perspective, the information in the type stub is typically more definitive than any type information inferred from the source. Type stubs often provide overloads, generic definitions, functions definitions with generic parameter types, etc. that the original source does not contain.

[tekumara]

By default, I was meaning which file was chosen for display first. In my case, I get the .pyi file displayed first:

Perhaps there a loading order somewhere that can be configured?

[jakebailey]

We should be selecting the py file first. The server does have control over which item it selects first. @huguesv

[huguesv]

@jakebailey VS Code ignores the server results ordering. I've tested by having the server reverse() the results before returning them, and it made no difference to the order displayed in VS Code, no difference to which one is selected.

Is there something in particular you were thinking of that would allow control over this?

[jakebailey]

Huh, I really had thought that the specification allowed you to mark one as the "preferred" choice. But, it's just a plain list? Unfortunately this'd mean we need the LSP to change to allow us to pick a result (or some change in VS Code to prefer the first one, for example).

[jgubler]

I'm also having the same problem. I understand that it may make sense in certain cases (overloading etc as you mentioned) to show the pyi file, so it probably shouldn't be hidden.
However I think the much much more prominent use case is "go to the source definition of this function/constant/etc to modify it", in which case it's obviously far preferable if the selected (and expanded) choice is the .py file.

[potatochip]

I don't even see an option to view the stdlib source. When I peek the module it only shows the typestub.

[killa1218]

I don't even see an option to view the stdlib source. When I peek the module it only shows the typestub.

I met the same problem and would appreciate if also add built-in class/functions into options choosing py or pyi.

[cangyin]

I don't even see an option to view the stdlib source. When I peek the module it only shows the typestub.

Please reopen the issue. I have searched so many issues that claims to be solved with lengthy discussions, but none of them actually helps me.

[erictraut]

@cangyin, you're commenting on an issue that has been closed for multiple years. If you have a question, please post it to the pyright discussion forum with details about your situation. If you think that you are seeing a bug, please create a new bug report with repro details.