As someone with minimal knowledge of LSP specifics, I'm a bit confused about why this exists. Is it the case that LSP alone does not provide adequate functionality for Python type queries?
As someone with minimal knowledge of LSP specifics, I'm a bit confused about why this exists. Is it the case that LSP alone does not provide adequate functionality for Python type queries?
> why this exists
https://docs.basedpyright.com/v1.40.2/type-server/
> The "type server protocol" is a desperate attempt from microsoft to prevent pylance from becoming obsolete by outsourcing its type checking to other language servers like basedpyright, ty or pyrefly -- while continuing to keep certain language server features exclusive to pylance.
> This protocol benefits nobody except microsoft. It adds needless complexity to any language server that chooses to support it. Basedpyright does not support it and strongly advises other language servers to avoid supporting it as well.
> For more info see here https://github.com/microsoft/pylance-release/discussions/718... and here https://github.com/astral-sh/ty/issues/1190#issuecomment-337...
Are language servers forced to support it?
It seems to be a more structured representation of the type. Normally in LSP you'd have a plain string or markdown that you render in the IDE, but nothing that you can analyse structurally.
It's a shame it's not just an LSP extension though, or a feature in a newer LSP version. LSP is maintained by Microsoft engineers.
workspace/symbol will do it (and the output may need some massaging), but it's optional.
I thought workspace/symbol returns an unstructured payload wrapped w/ some metadata.
Since the format is unspecified I imagine many language servers would just return a string representation of the type, which in Python is a PITA to parse because not every type has a closed-form representation (overloaded callable types, for example, have to be declared as a protocol).
Fair enough, I had no idea it was unstructured.