Type Server Protocol (github.com)
229 points by adamnemecek 13 hours ago
nikolatt 12 hours ago
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
ghm2180 11 hours ago
I think the only way MS knows how to make money is lock someone into an ecosystem. I think their next attempt should be a closed source lean checker that has will have proprietary code for NL -> lean formalization checker.
pjmlp 11 hours ago
Applies to all big tech contributing to FOSS, they don't do it out of charity.
salynchnew 5 hours ago
IshKebab 11 hours ago
endofreach 10 hours ago
anonymous908213 13 hours ago
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.
rzzzt 12 hours ago
Type Server Subsystem for Python
cobolexpert 11 hours ago
Copilot+ Type Server Subsystem for Python Series S
Waterluvian 11 hours ago
zemo 11 hours ago
Language Server Protocol Server Subsystem for Type Server Protocol Servers for Python
warkdarrior 7 hours ago
awesome_dude 6 hours ago
Python Server Subsytem Typing - PSST
wolttam 13 hours ago
It is namespaced under the pylance project. I also don't see any announcement here, just a markdown file.
Perhaps the post title could use a tweak
adamnemecek 12 hours ago
This was the announcement https://devblogs.microsoft.com/python/announcing-tsp/
roarcher 11 hours ago
This is the company that named its web framework "MVC". At least this time they're not eternally polluting search results for an industry standard term.
ameliaquining 10 hours ago
I've usually heard it called "ASP.NET MVC" except when the former part was clear from context.
Blackarea 13 hours ago
100% - it would make more sense if they also supported elixir or other dynamic languages
pantsforbirds 13 hours ago
I do wonder if it generalizes outside of python similar to how LSPs do.
fnord123 9 hours ago
So now I need a TSP AND an LSP eating loads of memory?
tobz1000 12 hours ago
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?
nextaccountic 8 hours ago
> 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...
Wilfred 11 hours ago
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.
zamalek 11 hours ago
workspace/symbol will do it (and the output may need some massaging), but it's optional.
ocamoss 10 hours ago
impoppy 4 hours ago
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.
benatkin 30 minutes ago
Indeed, this seemed not to happen to the same degree: https://ghuntley.com/fracture/
vscode forks were shown to be viable.
Tarean 13 hours ago
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.
pipes 12 hours ago
Can someone explain what this is to someone like me that doesn't know python very well, but programs a lot in c#?
jesuslop 11 hours ago
Language server protocol is the interface of a software piece that sits between an IDE and a language toolchain so you don't need to change code in the IDE to add support of new languages (you add support on the LSP server). Then server provides things such as completions/intelli-sense, navigation to definitions and some correction checking. From the anouncement TSP extends LSP for better python type awarness.
PufPufPuf 9 hours ago
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.
0cf8612b2e1e 12 hours ago
It kept with UTF-16. New protocol is a chance to correct that poor decision.
marshray 9 hours ago
It's just an .md file and a few hundred lines of json schema defining some extension messages, not a bottom-up protocol revision.
ivanjermakov 8 hours ago
What's wrong with UTF-16 for transport?
ashkankiani 6 hours ago
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.
_heimdall 6 hours ago
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?
rmzs0711 12 hours ago
Is there any application for that, except python?
ocamoss 11 hours ago
Right now it's specific to Python but I think there are other languages w/o an official type checker that might benefit.
PHP, Erlang, Ruby, etc.
dev_l1x_be 11 hours ago
The primary reason i guess is standardizing the type checking, so you can bring your own (3rd party).
wolvesechoes 11 minutes ago
Run server on your PC to serialize and deserialize JSON payloads back and forth just to get basic IDE functionality bro.
rjbwork 12 hours ago
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.
YuechenLi 12 hours ago
At this point, Python is less of a programming language by itself but more of an interop protocol between various C/C++/Fortran/Rust binaries. But again, it's just part of the cycle, Python was a breath of fresh air 10 years ago when academia is still dominated by Matlab, but now it is mostly a mess of a language that's good for throwaway scripts but not very convenient for large software projects compared to statically typed languages.
0gs 11 hours ago
thank you for putting this this way. it helped me crack a big unrelated problem
YuechenLi 10 hours ago
chuckadams 12 hours ago
I remember falling in love with Python when I first learned it at version 1.5, liked it even more with 2.0, but when 3.0 came around, that's when I noticed the ecosystem falling apart. Not for the obvious incompatibility schism: I do think most of 3.0's changes were good ones, and it finally is the standard default version now, but in many other ways it feels like the ecosystem has still never really recovered. Virtualenv is still the same grotesque hack, where rather than doing what other languages like Perl and Ruby do and making some wrapper around setting PYTHONPATH, it relies on python's behavior of locating the library path relative to the install, thus hardlinking a whole python installation in and making you "activate" it first. That nothing has managed to replace it in 20 years speaks volumes.
kenhwang 11 hours ago
I'm hoping one day people look at Python the same way they look at Perl and PHP.
There has been so much programming language innovation in the past decade that I'm surprised someone hasn't built a better Python. I'd like to see something like Rhai or Roto take off which has a natural upgrade path to Rust.
Maybe it's because interpreted languages just aren't in vogue anymore and probably won't be for a long time if humans aren't even coding anymore.
zamalek 9 hours ago
jacquesm 11 hours ago
Roughly the time when Guido stopped fighting the hordes. The hordes won, wrested the language away from its creator and now they own the pieces. 2 to 3 was the worst possible way a language has ever been upgraded bar none. Hilariously, even today Python 2 persists in many places because of this.
rspeele 11 hours ago
dist-epoch 10 hours ago
deathanatos 11 hours ago
> thus hardlinking a whole python installation in and making you "activate" it first
You don't have to activate a venv to use it; `$VENV_PATH/bin/python3` just works.
(It also softlinks/symlinks the binaries.)
benrutter 12 hours ago
I work in python daily, it's not necessarily my favourite language, but I'd say it's mostly fine.
What languages are you thinking of specifically when you mention better thought out ones?
rjbwork 11 hours ago
Pretty much every other mainstream language bar JS. I'd say also Ruby because I also do not like a lot of its choices, but there's at least a kind of heady elegance to it in a REPL, though I would never want to work on a production system written in Ruby.
Frankly, I just really prefer statically and strongly typed compiled languages.
I did my last company's first Demo and MVP in Python after running through the Koans at my co-founder's behest and ultimately we decided that the production system would not be done in Python. There are some cool things about it - specifically I do like that annotations are real AOP seams, but the numerous footguns and lack of types and a compiler just make it a very annoying ecosystem to work in for me.
pphysch 11 hours ago
They are a heavy C# user. Coke/Pepsi situation.
jelloroll42 8 hours ago
stackghost 11 hours ago
FacelessJim 11 hours ago
And the thing that maddens me the most is that it has a critical mass where it’s basically the default starting language and most people never really move from there. And so we’re stuck with this grotesque abomination that somehow keeps on rolling. The amount of money that was poured into python to make it barely bearable is probably the GDP of a small nation.
loeg 12 hours ago
I’m not a fan either, but it doesn’t bother me at all. Who cares? Let the python people do their thing.
lijok 12 hours ago
Fascinating take.
What do you attribute Python's success to, in spite of being a disaster of a language and ecosystem?
TomBombadildoze 10 hours ago
20 years working on Python. Two things have driven its success.
First, it's easy to learn and reasonably powerful. You can make a lot of useful things really quickly, which was true even 15 years ago. It's only gotten easier since, and the ecosystem has continued to grow.
Second, ML latched onto it. That gave Python a lot of credibility for people coming through CS programs and into industry, especially as AI use cases were picking up momentum. Think Tensorflow starting 10-ish years ago, then Pytorch, and so on.
[opinion time] Unfortunately, ML has contributed to disaster. The quality of software engineering in ML applications lags badly behind that in other segments, and there's where most Python development is happening now. The feedback loop of training Bad Python into LLMs is only making it worse. The skill floor was dropping, and now it's practically zero.
It also wasn't helped much by language design decisions. Gradual typing was a huge mistake. It would have been much better to go the Typescript route and define a superset of the language that compiles to native Python. The grafted-in typing features that rely on runtime behavior and never got an actual spec for a type system haven't helped.
rjbwork 22 minutes ago
https://en.wikipedia.org/wiki/Worse_is_better
We've known for a very long time that shitty things can become very successful in this field and why.
johnfn 12 hours ago
It's incredibly easy for new engineers to pick up. On the spectrum between "features easy for beginners but nightmarish for experienced engineers" and "features complex for beginners but great for experienced engineers" it always makes the tradeoff for the former.
dude250711 12 hours ago
kingstnap 12 hours ago
Probably the batteries included Standard Library.
Cross platform interpreter.
NumPy and SciPy really set the stage.
chuckadams 12 hours ago
timschmidt 9 hours ago
I'm not the OP, but it seemed to me that major teaching institutions settled on Python as a pedagogic language after previously having rallied around Java for same, and various other languages before that.
jacquesm 11 hours ago
BASIC rebooted. Right at the right time too, BASIC was never going to thrive in the days of the internet.
I'll give Python one thing though, it is by far the most elegant way to glue together a large number of otherwise incompatible C libraries.
thinkyfish 10 hours ago
They provide binaries for almost every open source library for every popular platform. If you need something, whatever it is, python was and is probably the easiest way to install and use it.
stronglikedan 12 hours ago
well, for one, my boss can use it and kinda understand it, so it must be dead simple
rsalus 12 hours ago
Definitely ease of use...
Pxtl 11 hours ago
It was the first language that actually felt ready-to-use, available for free-as-in-speech. Batteries included, robust online development community, sensible featureset, main libs that were designed bottom-up instead of top-down. I remember learning Java 1.2 or 1.4 after learning Python and it felt like a huge regression. Swing was a joke compared to TkInter (which was weak compared to proper GUI editors like VB but at least made nice scalable native-feeling GUIs and had a sensible API) and the standard collections were miserable without generics.
But Python peaked like 20 years ago. The later features were too ugly, and it was too slow to fill the obvious gaps in the language.
aaabbbbb 12 hours ago
Marketing in academia, decent C-API that led to use in scientific Python.
The language is a disaster since it deviated from its original purpose. The community is ruled by insane, mediocre narcissists who drove away all reasonable people.
avaer 12 hours ago
- Math + visualization libraries (which ironically have to break out of Python to do their job)
- Reasonable ergonomics for describing data flows, as long as you never run the code, which you often don't care about if you're a mathematician
- Adoption by people who optimize pumping citations, not reproducible results -- non-working code is a feature when you're trying to BS
wiseowise 11 hours ago
No other language came even close to a combination of easiness and expressivity of Python.
svachalek 11 hours ago
I've been thinking recently, there's hardly any reason not to use a native language like Rust anymore. The classic reasoning for languages like Python is that it prioritizes developer time and resources over compute resources, but now developer time is rapidly trending to zero and everything is compute dominated.
joshheitzman 11 hours ago
Not having to build still saves wall clock time. Also Python is a concise language (fewer tokens in context) with a monster ecosystem that avoids a lot of code having to written by agents (fewer tokens for the current task and fewer for future tasks by keeping the code base smaller).
hocuspocus 10 hours ago
kenhwang 11 hours ago
Rust has Rhai and Roto too if you need better than Python level of developer considerations.
gostsamo 11 hours ago
Unpopular take, but:
I work in python. It's only real and big issue is the slow interpreter. Everything else is resolvable one way or another. The only other big issue it has is the envy of people who imagine that if not for python, their beloved language would be as used as python is now. Most of their beloved languages are older than python or when they were created, they had much bigger ticket backing than python and those languages are still not where python is. The reason? Python is made to solve the issue one has now, not the issue one might have in the future. Local optimum at its best and worst. And honestly, most people have the current issue to solve and rarely reach the imaginary issue to be. If python didn't exist, it would have been invented.
FridgeSeal 7 hours ago
The issue is that it just becomes a “bad at everything” tarpit.
- performance is awful.
- gradual typing is sort of ok, but relies too much on runtime behaviour.
- async support is a bit all over the place.
- uv has made the packaging experience sort of liveable, but collectively it’s still very limited: feature support, conditional dependencies, rudimentary tree shaking, cargo-style workspaces, etc.
In an era where your options of tech stack are freer than ever, unless you explicitly need PyTorch, I’m not really sure why you’d choose Python over literally everything else.
trojans1290 18 minutes ago
risyachka 12 hours ago
I will take Python over typescript every second of every day. TypeScript is just so unreadable compared to Python.
mi_lk 12 hours ago
OTOH I don't want to live in a universe where Haskell wins
Toutouxc 12 hours ago
As a Ruby dev I'm kind of primed to hate on Python a little bit, but I have to agree. I've written some Python over the years, I've tried to like it, but it just doesn't feel good to me. There are things that are really great about Rust, Elixir, C#, Swift, Java, Common Lisp... Sometimes it's the standard library, sometimes the package manager, sometimes a feature (borrow checker, pattern matching), sometimes a principle (everything is an object, the code is just data). In Python, everything is kind of meh. Like they came up with the list comprehension syntax and that was it for cool things.
Pxtl 11 hours ago
List comprehensions? Really? I remember when they were pretty and I was learning them alongside other languages with higher order functions and Python's approach seemed to be the ugliest of its cohort. They were neither as logical as simple Lispy "take a function as a parameter" things like Ruby, nor were they the kind of clean and legible stuff we expect from Python.
Toutouxc 11 hours ago
brcmthrowaway 12 hours ago
The packaging is a nightmare thats for sure.
Venvs, activate, deactivate, shitty scripts hacking on $PATH. How did this ever ship? Then there was poetry, `uv`, and maybe something in else in $CURRENT_YEAR.
Try to set it up on a new macOS, go on. Install a package from pip, and there's a bunch of garbage that won't let you do it.
It's horrible. Python packaging engineer is now an FTE, maybe that's what they wanted.
Pxtl 11 hours ago
The fact that they didn't solve Venv when they did the breaking change in Python 3 is absolutely bonkers.
globular-toast 11 hours ago
Python had no corporate backing, no marketing, it became popular because people actually like to use it. Sorry you've only been using "better thought out languages" instead.
westurner 11 hours ago
Python should have done runtime type checking instead of compile-time only String and List annotations and so on
esafak 12 hours ago
Worse is better. Avoid using it yourself and tell others; that's the best you can do.
quotemstr 12 hours ago
Python is pretty decent. What are you talking about?
okanat 11 hours ago
The syntax and meaningful spaces are annoying. The dynamic typing is abused to hell in everything including the standard library. It has wacky paradigms like "exceptions instead of conditionals" or having "else" clause for loops.
It lacks decent packaging and by design cannot handle multiple versions of dependencies or perform metadata-only/declarative resolution. To resolve the dependencies of a Python package you need to install it. Many Python packages resolve their dependencies imperatively depending on the current system state. When you need binary dependencies like numpy it gets even worse since libpython doesn't have a stable ABI.
It is one of the most underdesigned languages but it holds a dear place due to being easier to translate from pseudocode to actual implementation. This resulted many academics to pick it up and write advanced math libraries in it.
Quitschquat 12 hours ago
I blame Perl 6
theplumber 12 hours ago
it could be worse like …PHP
mathisfun123 12 hours ago
> It's a disaster of a language and ecosystem
"unhinged" take
paaloeye 13 hours ago
Interesting, LSP, DAP, MCP, and TSP now...
intrasight 12 hours ago
TSP : TriSodium Phosphate. Very good for cleaning up a mess.
paaloeye 10 hours ago
From Wiki:
Trisodium phosphate was at one time extensively used in formulations for a variety of consumer-grade soaps and detergents, and the most common use for trisodium phosphate has been in cleaning agents.
paaloeye 10 hours ago
Is it Python specific only?
madelgi 10 hours ago
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
ChrisArchitect 12 hours ago
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
ahgrta 13 hours ago
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?
SwamyM 11 hours ago
> Why don't you spend your resources on F# instead of this nonsense?
Absolutely!
F# is criminally under-invested in.
rednb 11 hours ago
Exactly what i came to write as well. I'd expect Microsoft to invest in F# so that python can slowly fade away the way php did.
arionmiles 10 hours ago
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...
pacman1337 11 hours ago
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.
wargames 10 hours ago
100%. This is a solution to a problem you wouldn't have if you were just using a statically typed language. AI will naturally drive us to more rigid languages.