Python LSP Server works great, is easier to install and even offers some optional extensions.

https://github.com/python-lsp/python-lsp-server

In the interim, check out basedpyright [1]. It's an up-to-date fork of pyright with some improvements, less arbitrary limitations, and does not require npm to install.

[1] https://github.com/detachhead/basedpyright

Agree that this looks useful. I actively do not want NPM in my toolchain.

Pyright requires npm?! Wtf!

I dug into Pylyzer a few weeks back when scoping out alternatives for faster type checkers, as we have a lot of brittle Python code that we are gradually migrating in at $DAYJOB. I got the idea in my head to basically build mypy but in Rust, similar to what Ruff has done.

My research agrees with your assessment. While I'm sure it's a lot faster (I think the README implies it's one or two magnitudes faster) it just doesn't sit right to me that it's essentially just transpiles to Erg and delegates the actual hard work to the Erg typechecker. This works, but I feel like it fundamentally limits what Pylyzer is capable of, and how much control it really has over the underlying type checking process, as to it, the Erg type checker is essentially a black box.

It's a wrapper (a non-trivial one, to its credit -- especially considering everything is a wrapper if you look at it the right way -- but still a wrapper) rather than an actual full solution.

There's also really only one maintainer (who seems to do a decent job, but I don't seem to recall much more than just bug fixes). Makes me hesitant to really depend on it sticking around long-term or having features that meaningfully progress in the future.

It's also made by the top contributor to erg (github user mtshiba), and erg is trying to be a compiled typed python.

If you're already making that then building a type checker wrapper on top of it makes perfect sense.

They say as much in the readme

I wonder if a better use of time would be to just focus on making mypy faster. We already have too many tools, and it's often better to just focus on making the existing stuff better rather than developing a new tool (relevant XKCD [1]). There's gotta be ways to make mypy faster, even if it takes some breaking changes.

One consideration there would probably be how many committal decisions mypy has made. One of the main reasons a new tool might be better than an old one is that it can be built fresh, with all the lessons learned but (essentially) none of the baggage of bad design decisions.

Another thing I've also weighed is that developing any kind of static analysis tool whose source code is not in the language it analyzes (such as Ruff) immediately blocks you off from a large portion of maintainers. Your maintainers cannot be your end users unless they work with both Python and Rust. While Python is definitely one or more magnitudes slower than Rust, I can't imagine that mypy is at the point where the language choice itself is the only bottleneck.

[1] https://xkcd.com/927/

I haven't actually tried it out, but have done a bit of research in the name of scoping a competing product, and my verdict is that it's probably too immature to be worth production usage. It also makes the design decision to delegate most of the actual hard work (the type checking) to the type checker of Erg, a strongly typed superset of Python, which leaves a lot of decisions and agency out of the purview of Pylyzer itself. There will always be limitations that can only be resolved upstream.

Granted, maybe there's value in this just being a wrapper, and it's best to just deduplicate the work. However, it just sits a little wrong to me that it's not type checking Python, it's doing a transpilation step of sorts and type checking that.

From the README:

"Ruff, like pylyzer, is a static code analysis tool for Python written in Rust, but Ruff is a linter and pylyzer is a type checker & language server. pylyzer does not perform linting, and Ruff does not perform type checking."