Type Server Protocol

DetachHead (maintainer of basedpyright) has criticized the TSP before:

- 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

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.

It’s really good that folks over at Astral decided to implement it. It was difficult for me to understand what does this protocol provide that couldn’t be implemented with a new LSP capability, the linked document doesn’t really explain that, but what did become clear to me is that seemingly Microsoft are trying to invent new features for their proprietary LSP server that only works in VS Code so people will have harder times switching to other editors. This way, no matter what Microsoft comes up with, will be matched with very high quality open source tools.

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.

Can someone explain what this is to someone like me that doesn't know python very well, but programs a lot in c#?

I just use the Pyrefly extension in VSCode/Zed, run Pyrefly in the CI, and everything works well. The fragmentation around pyright/pylance/basedpyright/cursor-pyright etc. makes it pretty much unusable, you can't get consistent results across IDEs.

It kept with UTF-16. New protocol is a chance to correct that poor decision.

When I wrote the initial version of the neovim LSP client, I got intimately familiar with LSP, and how much I hate it. Microsoft protocols have a habit of being extremely specialized to their application despite being recommended for broader use. I will never, ever, ever adapt another microsoft language protocol.

Reading the main README, I'm not sure why I'd reach for this over ant other typed JSON RPC, tRPC or similar. What are the benefits I'm missing here?

Is there any application for that, except python?

The primary reason i guess is standardizing the type checking, so you can bring your own (3rd party).

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.

Interesting, LSP, DAP, MCP, and TSP now...

Is it Python specific only?

i primarily work in python and from a language-design standpoint, sure, there are generally better options out there. but all the people convincing themselves that a language with this much of a user base and this large of an ecosystem will fade away because of ai or some other reason are deluding themselves. i'm sure the death of python will be imminent for the next several decades, just as it has been for java

Blog posts:

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/

Run server on your PC to serialize and deserialize JSON payloads back and forth just to get basic IDE functionality bro.

Type-shed, type-server. When can this Python madness stop? How about using CORBA to make it even more enterprisey?

Why don't you spend your resources on F# instead of this nonsense?

[flagged]

[dead]

[dead]

[flagged]

The cottage industry around fixing gaps in Python is sometimes awe-inspiring and most times just downright awful.

Maybe just make a Python 4 with better types built in at this point...

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.