pyre-check VS typing

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.

Python now has an optional type system and if you add one of them such as mypy or pyre to your CI process and you can configure GitHub to refuse the pull request until types are added you can make it somewhat strongly typed.

If you have a preexisting codebase I believe the way you can convert it is to add the types that you know on commits and eventually you will have enough types that adding the missing ones should be easy. For the missing ones Any is a good choice.

https://pyre-check.org and https://github.com/python/mypy are popular.

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.

The basic motivation behind them is that functions can have arguments that can only take a specific set of values, and those functions return values/types change based on that input. Common examples are (you can find more here):

While yes 26 people liked the idea here: https://github.com/python/typing/issues/193

but looking at relevant issues on GitHub it seems this has been shot down repeatedly. python/typing#18, python/typing#213

See https://github.com/python/typing/issues/256 for a discussion.

Lower bounds are not supported for TypeVars, unfortunately.

Mypy allows that because initial versions of PEP-484 allowed that. This has changed; here's the current wording on the PEP:

> This is no longer the recommended behavior. Type checkers should move towards requiring the optional type to be made explicit.

https://www.python.org/dev/peps/pep-0484/#id29

Dunno, other, larger projects than the one I'm working on seem to run up against this from time to time. (rasa_core, to pick one example from near the top of a Google search; also Telethon, Blender, TensorFlow, Pandas. Guido also filed a bug on the typing module in an early version of Python 3.5 because of unexpected implications of this particular issue, so the problem isn't exactly purely theoretical.) That's aside from the wish for conceptual purity in the call signatures of classes and their subclasses, which is not always and automatically a bad wish to have; and the notion that a language that prides itself on its introspective faculties might want to make introspection of classes from the top of a class hierarchy possible, at least in theory? Perhaps to facility learning about the language and/or visualizing large class hierarchies easily, for instance?