Skip to content

Surface the "source definition" over the stub definition #788

@MichaReiser

Description

@MichaReiser

Untyped libraries use stub files (.pyi) to give downstream users a typed API even though the library itself might be untyped (or not fully typed). The stub files are all we need for type checking and ty's module resolver returns the stub files if both a regular python file and a stub file are present. That means, a type's Definition always points to the Definition in the stub file. This is fine for type checking but having access to the source definition has advantages for the LSP use case:

  • A user wants to jump to the source definition when using go-to definition (except for go-to declaration?)
  • Stub files often lack documentation because the source definition is documented.

This requires:

  • Adding logic to resolve the location of the standard-library source files from a system or virtual environment's sys.prefix value
  • Extending the module resolver (see resolve_module) so that it can be parametrized whether it should return the stub or source file. We have a few options here:
    • Add a source field to Module and always populate it when the resolved module is a stub (this goes a bit against or lazy approach as the source file is only needed in the editor context for now)
    • parametrize resolve_module
    • A new method to resolve the source module
  • Adding a new method to Definition to resolve the source_definition if it is defined in a stub file. This will require some heuristic for how we map a stub definition to a source definition.
  • Use the source definition when extracting docstrings, in go-to definition, ...

Metadata

Metadata

Assignees

Labels

serverRelated to the LSP server

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions