Hacker News Reader

Comment by extr | Hacker News Reader

What is the smart money doing for type checking in Python? I've used mypy which seems to work well but is incredibly slow (3-4s to update linting after I change code). I've tried pylance type checking in VS Code, which seems to work well + fast but is less clear and comprehensive than mypy. I've also seen projects like pytype [1] and pyre [2] used by Google/Meta, but people say those tools don't really make sense to use unless you're an engineer for those companies.

Am just curious if mypy is really the best option right now?

[1] https://github.com/google/pytype [2] https://pyre-check.org/

View on HN

I have extensive experience of MyPy and Pyright, even going so far as to try to fix a but in MyPy (I couldn't do it; the code is too much of a legacy undocumented mess).

Pyright is much much better. If you're starting a new project or work with people who understand the value of type hints and want to actually fix them (ha yeah right) it's a no brainer. It's also the default in VSCode which is nice. Oh and they guy that maintains it is a bug fixing machine.

The only reason you should consider MyPy is if you're adding types to a big existing project or you're working with people that don't get it. MyPy has way more "eh whatever" options so it doesn't give you a barrage of errors when you run it for the first time.

But other than that you should use Pyright. No contest.

I'm on the other end of the spectrum — I only write Python occasionally for smallish utility tools, just a step above shell scripts — so I'll give my input as someone relatively new to typed Python. I recently industrialized (to use the terminology from other comments here) a couple things that I'd originally done in quick-and-dirty Python 2 over a decade ago. My experience was that mypy had a handful of false positives, and pyright had none. Pyright also found one comparatively subtle mismatch that mypy didn't, although its error message in that case was incomprehensible to me.

(I also used pylint and pytest+coverage.py; interested whether there are better choices for next time.)

I also have extensive experience with mypy and pyright, also even going as far as trying to fix a mypy bug (also unsuccessfully). For pyright, the dev was so responsive that I only had to report bugs for them to be fixed (sometimes in a couple of hours).

It's been a year or two since I've touched Python, but back then, Pyright, was way faster, was more feature-complete, had a much more responsive dev team (of 1). It was better literally along every metric: except that it didn't support custom extensions to the type system like mypy did. But that wasn't a huge issue since there were very few extensions, and even the one that was developed by a mypy core dev for sql-alchemy was hopelessly out-of-date, or impossible to get working. So I didn't miss it much.

All this to say: pyright was much better.

I just did some highly unscientific spelunking on the topic a couple hours ago, and my takeaway was more or less that a bunch of people on reddit said pyright was better.

You may already know this, but Pyright and Pylance are the same thing.

"Under the hood, Pylance is powered by Pyright," https://marketplace.visualstudio.com/items?itemName=ms-pytho...

I've been using Pylance with `"python.analysis.typeCheckingMode": "basic"` for a long time and have found it quite good. Most of the time, the problem isn't Pylance/Pyright, but poor or wrong type annotations in third-party libraries.

Maybe they produce the same results (I don't know), but Pylance using Pyright doesn't mean that Pylance is Pyright.

One important difference in this case is that while "Pylance leverages Microsoft's open-source static type checking tool, Pyright" [1], Pylance itself is not open source. In fact, the license [2] restricts you to "use [...] the software only with [...] Microsoft products and services", which means that you are not allowed to use it with a non-Microsoft open source fork of VS Code, for example.

The license terms also say that by accepting the license, you agree that "The software may collect information about you and your use of the software, and send that to Microsoft" and that "You may opt-out of many of these scenarios, but not all".

[1] https://github.com/microsoft/pylance-release

[2] https://marketplace.visualstudio.com/items/ms-python.vscode-...

Ruff [0] is the best linter around for performance but I'm not sure how well it fills the static analysis role. It has a vscode extension which updates the linting with no noticeable lag but it isn't a full fledged type checker. Their suggestion is to run ruff through the vscode extension and then manually run mypy or whatever type checker on occasion (maybe as a pre commit hook?).

[0] https://github.com/charliermarsh/ruff

Has anyone managed to get ruff to work when run as a pre-commit hook in a project whose deps (such as python and pre-commit) are declared in a flake.nix?

I love being able to pop between devices and have a uniform dev experience everywhere, but ruff is a thorn in my side. pre-commit can't be told to just use the ruff binary /nix/store and fails to install it correctly, so things get hacky.

For your mypy performance question, make sure it's using incremental mode [1] so that it can skip checks on code that didn't change. Yes, it is probably among the slowest of type checkers, but it is also quite thorough.

[1] https://mypy.readthedocs.io/en/stable/command_line.html#incr...

It sounds like incremental mode is the default now? I've noticed that it runs much faster after the initial run, with no special configuration

But that link also mentions daemon mode [1], which supposedly "can be 10 or more times faster", so that could be something to try. Running as a persistent server with an in-memory cache is probably part of why LSP-based type checkers like Pyright can perform better than mypy.

[1] https://mypy.readthedocs.io/en/stable/mypy_daemon.html#mypy-...

I'm using pyright at the moment. It's ok. Feels better than mypy. If you're used to counting on the type system to guarantee your invariants, you'll be disappointed, but if you're just looking for fewer TypeError, it will help.

Have tried ruff? It is a Python linter with a speed in mind.

I'm really happy with Pyright.

Reply on news.ycombinator.com