Show HN: A Mypy-Compatible Python Language Server Built in Rust
9 davidhalter 6 6/16/2025, 10:56:19 AM zubanls.com ↗
Having created Jedi in 2012, I started ZubanLS in 2020 to advance Python tooling, with a focus on performance and Mypy-compatibility. Ask me anything.
> Some of you may wonder why ZubanLS isn’t open source, unlike Jedi. The honest answer is that open source never worked out for me financially. Beyond some small donations and a small recurring compensation from Tidelift, I was never able to make a living from it. I'm no longer a student, and with a family to support, it became clear I needed a sustainable path.
> Joining a company like Astral (makers of Ruff) could have been an option—but I’ve also grown skeptical of venture capital as a model. VC-backed companies often need to aim for massive success or risk disappearing within a decade. I want to build something that lasts. I’ve already spent more than ten years in this space, and I plan to continue.
https://zubanls.com/blog/release/
Best of luck!
Without mypy cache:
With mypy cache without any changes: mypy with a small change in a shared module zmypy: Without caching and parallelization (as the 99% CPU usage indicates) it comes in the range of mypy using the cache and multiple cores (628% CPU usage) without any changes in the code.zmypy seems to find more errors but they mostly boil down to the following errors
* Call to untyped function "__setitem__" in typed context
* ... has incompatible type "MagicMock"; expected ...
Maybe __setitem__ and MagicMock are treated specially in mypy? Also there seem to be differences in handling Protocol and enum comparison.