Python's type system was specified in PEP 484. If you are new to Python's type system and want to learn the basics, we highly recommend you take a look at mypy's cheatsheet as well as their type system reference. The following discussion focuses on Pyre's approach to "gradual typing" and how you can get from an untyped codebase to a fully typed codebase.
Most Python code does not (yet) start out typed. PEP 484 specifies a gradual type system, which is built to allow you to gradually add annotations over time. It does so by
- only reporting errors on functions that have an explicit return type annotation,
- introducing an escape hatch: a special type
Anythat has all possible attributes and is both sub- and super-type of any other type,
- and assuming that all untyped fuctions implicitly return
In combination, these rules allow you to slowly annotate code without getting overwhelmed by type errors in one sitting. Incrementally adding more annotations will give you stronger safety and consistency guarantees in your codebase.
In the example above, if you changed
unannotated to return
str, you would get a type error when accessing the attribute
Any is a necessary escape hatch when annotating large codebases over time, it can hide legitimate type errors. We've introduced strict mode in Pyre to address this problem. Strict mode can be toggled at a module level by introducing a
# pyre-strict comment to the file. In strict mode, Pyre will
- run on all functions, whether they are annotated or not,
- error on functions, globals, or attributes that are missing annotations,
- and error on annotations containing
Any(with some exceptions to accommodate for common patterns).
In our previous example,
As you can see in the example,
Any can still sneak into modules that are strict, but increasing strict coverage and fixing the surfaced errors will gradually eliminate them.
Strict mode can also be set as the default in a project configuration. To opt individual files out of strict mode, use
# pyre-unsafe in place of
We do not always have access to all the source code that contributes type information to our project: e.g.
builtins is compiled native code, and other libraries may be using cython. Other times, we may be working with Python code that is just too dynamic to be reasonably typed.
To address these cases, Pyre will give precedence to type stub files with a
*.pyi extension over source files when these are specified in the search path in the project configuration or if they are located next to the implementation file.
Stub files have the same structure as implementation files but only contain class and function signatures:
__getattr__ function is defined in the stub file as follows, Pyre will take it as a signal that the stub file is partially complete: accessing attributes whose name is not defined in the stub file will result in
Any instead of a type error.
Pyre comes with tooling to make it easy to increase type coverage in your project.
When upgrading the type checker, new errors inevitably get surfaced. In order to keep a codebase clean through upgrades we've built
pyre-upgrade, which automatically suppresses newly surfaced type errors. It takes Pyre's output and adds supression comments to the code explaining what's wrong so that developers can easily address the issues individually.
You can run
We have found tools that automatically add type annotations to code useful to get started with a project. There are two general approaches to automatic type inference: static inference and dynamic inference from runtime information. Both approaches come with their own trade-offs and we have found a combination of the two to be useful.
Pyre can do static type inference. You can run
to automatically apply annotations.
For dynamic inference we recommend you give MonkeyType a try.