pyre-check VS typing

is used with the type checkers such as mypy, pyright, pyre-check, pytype, etc.

Did you come across pyre in your search? MIT license and pretty fast.

https://github.com/facebook/pyre-check

Pyre is a performant type-checker developed by Facebook. Pyre can analyse codebases with millions of lines of code incrementally – providing instantaneous feedback to developers as they write code.

Pyre from Meta, pyright from Microsoft and PyType from Google provide additional assistance. They can 'infer' types based on code flow and existing types within the code.

Have you seen Pyre[0]? Not Rust, OCaml, and pretty fast. Made by a team at Meta and open sourced on GitHub. If you use python-lsp, I wrote an extension[1] to enable integration (though I haven't tested it recently, been programming in rust; it is mostly a "for me" extension).

0: https://pyre-check.org/

1: https://github.com/cricalix/python-lsp-pyre

Internally we use Pyre for Python type checking: https://github.com/facebook/pyre-check

Before type hinting, work had intense rules and linters enforcing docstrings with types. Now, type hints and automatic pyre runs take care of all the heavy lifting.

- https://github.com/python/typing/issues/242

Indeed.

IMO, the trick to really enjoying python typing is to understand it on its own terms and really get comfortable with generics and protocols.

That being said, especially for library developers, the not-yet-existant intersection type [1] can prove particularly frustrating. For example, a very frequent pattern for me is writing a decorator that adds an attribute to a function or class, and then returns the original function or class. This is impossible to type hint correctly, and as a result, anywhere I need to access the attribute I end up writing a separate "intersectable" class and writing either a typeguard or calling cast to temporarily transform the decorated object to the intersectable type.

Also, the second you start to try and implement a library that uses runtime types, you've come to the part of the map where someone should have written HERE BE DRAGONS in big scary letters. So there's that too.

So it's not without its rough edges, and protocols and overloads can be a bit verbose, but by and large once you really learn it and get used to it, I personally find that even just the value of the annotations as documentation is useful enough to justify the added work adding them.

[1] https://github.com/python/typing/issues/213

[1]: https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html

Two examples that come to mind are: https://discuss.python.org/t/pep-692-using-typeddict-for-mor...

and: https://github.com/python/typing/issues/1252

preview: <https://htmlpreview.github.io/?https://github.com/python/typ...>

Pyright was itself a big improvement over Mypy. Just look at this for starters: https://htmlpreview.github.io/?https://github.com/python/typ...

If Astral can leapfrog pyright too, great. But I think it will be significantly harder than leapfrogging flake8 and black.

Iterable[str] is unfortunately evil as it matches str which is often unintended. (see: https://github.com/python/typing/issues/256) One would need both NOT-type and AND-type in order to properly handle these.