Hacker News new | ask | show | jobs
by rikthevik 519 days ago
I'm very impressed by the recent developer experience improvements in the python ecosystem. Between ruff, uv, and https://github.com/gauge-sh/tach we'll be able to keep our django monolith going for a long time.

Any opinions about the current state of the art type checker?

5 comments

I'm very happy with pyright. Most bug reports are fixed within a week and new peps/features are added very rapidly usually before pep is accepted (under experimental flag). Enough that I ended up dropping pylint and consider pyright enough for lint purposes as well. The most valuable lints for my work require good multi-file/semantic analysis and pylint had various false positives.

Main tradeoff is this only works if your codebase/core dependencies are typed. For a while that was not true and we used pylint + pyright. Eventually most of our code is typed and we added type stubs for our main untyped dependencies.

edit: Also on pylint, it did work well mostly. tensorflow was main library that created most false positives. Other thing I found awkward was occasionally pylint produces non-deterministic lints on my codebase.

Everyone is already recommending pyright, but I'll suggest checking the "based" community fork: https://github.com/detachhead/basedpyright

Besides re-adding features that Microsoft makes exclusive to pylance, it tweaks a number of features that IMO makes pyright work better out the box:

https://docs.basedpyright.com/latest/benefits-over-pyright/p...

Thanks for linking this. I wasn't surprised Microsoft made their AI auto completion proprietary (they did similar for C# in VSCode). But it grated me that semantic highlighting wasn't open source.
What did they do for C#?
They added some closed source features to the C# developer extension in VSCode. So anybody using a non-Microsoft fork of VSCode can't use those features.
If you are referring to the debugger, they did not "add" it - it was like that from the start. The C# extension is MIT, but the 'vsdbg' it ships with isn't because it's a debugger Visual Studio uses made into a standalone cross-platform component.

You can use an extension fork which swaps it with NetCoreDbg maintained by Samsung instead. This is what VSCodium uses.

Also note that both of these essentially consume the debugger API exposed by the runtime itself, you can easily make one yourself in a weekend but no one bothered because there isn't much need for another one.

Personally the thing that annoys me isn't so much the open vs closed source of (parts of) these extensions, but the blocking of using these extensions on VSCode forks.
I have always used MyPy but I have noticed some large open source projects adopt Pyright as of late. The folks behind ruff and uv are currently working on a type checker as well but haven't heard when they plan on releasing it.
MyPy is nice, but it has missed some things that pyright caught, which were legitimate bugs that could have arisen.
has Astral confirmed they’re doing a type checker? i’m not surprised, everyone has been asking for it, but i haven’t seen them say they’re doing it
Yes it's confirmed, you can listen to Charlie talk about here: https://youtu.be/byynvdS_7ac?si=JWeeD3uwXflWl5jo&t=1980

Code Name is Red Knot: https://github.com/astral-sh/ruff/discussions/12143

First thanks for mentioning tach, I wished this tool existed for a long time and I'm happy to give in a try in the following days!

For typechecker, I also vouch for Pyright which is what we use for all our django backends at work.

Just be aware that you will have hard time to typecheck part of your code where you rely heavily on django's magic (magic strings, auto-generated properties/methods, etc...).

In these cases, it's sometimes better to avoid these features entirely or accept that some part of your code will not be typechecked.

I haven't dug into tach yet, but I'm very optimistic on this one.
Pyright is pretty good. It's easy to setup, and has first-class VSCode support, if that's what your team uses.