What does HackerNews think of pyright?

You can use pyright instead[0]. It is the FOSS version of pyright, but having some features missing.

[0]: https://github.com/microsoft/pyright

I've had lots of success using pyright [1] for Python projects, it has sensible defaults and can be configured with a pyproject.toml file so everyone's using the same settings. I use the Pylance VSCode extension to catch errors earlier, but I also put it in pre-commit and as a CI check, so all contributors are committing the same quality of typed code.

With more complex types, I've found it isn't necessary to do anything more complex than specifying the element type of a list or dict most of the time. I have typehinted lambda function arguments before, but just using the plain Callable typehint is usually enough. When I forget if I need to use an Iterator or an Iterable (which is every time), then I just try one and run the type checker and change it to the other if i guessed incorrectly.

Type checking Python can become complex if you expect to be able to express everything in the typehints, but Python's type system isn't powerful enough for that. I feel its strength is that it lets you add as much detail to the types as is convenient.

[1] https://github.com/microsoft/pyright

The only one that's stuck with me is https://github.com/microsoft/pyright, mainly because I thought it was strange that Microsoft would publish something such a lackluster README. It's not the worst ever, but it lacks a clear sales pitch and a concise explanation of why you'd use it instead of mypy. If you go in without that added context, it's kind of mystifying why it even exists or why you'd use it compared with the alternatives.

pytype dev here - thanks for the kind words :) whole-program analysis on unannotated or partially-annotated code is our particular focus, but there's surprisingly little dark PLT magic involved, and you certainly don't need to be an academic type theory wizard to understand how it works. our developer docs[1] have more info, but at a high level we have an interpreter that virtually executes python bytecode, tracking types where the cpython interpreter would have tracked values.

it's worth exploring some of the other type checkers as well, since they make different tradeoffs - in particular, microsoft's pyright[2] (written in typescript!) can run incrementally within vscode, and tends to add new and experimentally proposed typing PEPs faster than we do.

[1] https://github.com/google/pytype/blob/main/docs/developers/i...

[2] https://github.com/microsoft/pyright