This should be called Python Type Server Protocol, no? Seems weird to mine the generic protocol namespace for a protocol that only supports Python. Especially coming from the company behind LSP, which actually is generic.
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?
So basically adding machine readable type-at-point queries as an lsp extension so Pylance and Pywright can be separated?
The 'result types'format is super python specific, like not having a for all binder. I don't think this specific schema will be used for any non-python languages.
It's such a shame python got such mindshare. It's a disaster of a language and ecosystem that people keep bolting and hacking things that much better thought out languages have had for decades.
languages with dynamic types will be obsolete thanks to AI, you heard it here first. It is just introduces more errors, with AI you want formal checking, sure static types are not that, but it is a small piece of it. If 10 percent of errors are types, with a typed language keeping everything the same you have 10 percent less errors, simple as that.
- https://docs.basedpyright.com/v1.40.2/type-server/
- https://github.com/microsoft/pylance-release/discussions/718...
Ty (the type checker maintained by astral) however will apparently support the TSP: https://github.com/astral-sh/ruff/discussions/23432
The 'result types'format is super python specific, like not having a for all binder. I don't think this specific schema will be used for any non-python languages.
Pylance + Pyrefly: bring your preferred type checker to Visual Studio Code
https://devblogs.microsoft.com/python/announcing-tsp/
Pyrefly + Pylance Integration in VS Code
https://pyrefly.org/blog/pyrefly-pylance/
Why don't you spend your resources on F# instead of this nonsense?