Comment by IshKebab | Hacker News Reader

Comment by IshKebab | Hacker News Reader

Parent Full thread

I found performance not that different to Pyright. The major difference is quality and correctness. Mypy is full of weird bugs and insane typing holes.

I found cases where it would even treat `foo: SomeType` and `foo # type: SomeType` differently!

I tried to fix that one but looking into the code lowered my impression of it even further. It's a complete mess. It's not at all a surprise that it gets so many things wrong.

Overall Mypy is like kind of like a type checker written by people who've only ever seen linters before. It checks some types but it's kind of wooly and heuristic and optional.

Pyright is a type checker written by someone who knows what they are doing. It is mostly sound, doesn't just say "eh we won't check that" half the time, and has barely any bugs.

Seriously check the closed/open issues on Github - there's a touch of "I disagree so I'm closing that" but only a touch. It mostly has so few open issues because the main author is a machine.

The only real problems with it are performance (it's ok but definitely could be better), and the slightly annoying dependence on Node.

I upvoted as your comment sounds reasonable, but in a sibling comment I see:

>By comparison [to pyright], mypy uses a more traditional multi-pass architecture where semantic analysis is performed multiple times on a module from the top to the bottom until all types converge

That makes it sound like mypy does in fact do The Right Thing (albeit the slower, less-suitable-for-LSP thing), rather than a messy pile of heuristic/optional hacks.

> It is mostly sound, doesn't just say "eh we won't check that" half the time

No, but they did kinda say that about `attrs`, which is a big deal for me and my stuff at least. Hopefully this new project can deal with all the crazy dynamic stuff python allows you to get away with.

> Hopefully this new project can deal with all the crazy dynamic stuff python allows you to get away with.

Unlikely. It's best not to write code like that in the first place.

Not really knowing fully about how type checkers work, one thing I struggled with a fair amount working with Mypy is how the stubs made available from various libraries were both all over the place in quality and not straightforward as a beginner to get working. Is this approach of using stubs a requirement for basically any static type checker that Python uses, or is this a specific way that Mypy chose to implement this concept?

Yes, I think that is actually the greatest weakness of mypy: the ecosystem is hostile to static typing.

Reply on news.ycombinator.com