Types in Python
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.
Why Types?β
Gradual Typingβ
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 or parameter type annotation,
- introducing an escape hatch: a special type
Any
that has all possible attributes and is both sub- and super-type of any other type, - and assuming that all untyped fuctions implicitly return
Any
.
For example,
from typing import List
def unannotated(): # implictly returns `Any`
return b"" + "" # function body is not checked
def annotated() -> List: # explicit return annotation means we type check `annotated`
any = unannotated()
any.attribute # `Any` has all possible attributes
return 1 # Error: returning `int` but expecting `List`
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.attribute
in annotated
.
Strict Modeβ
While 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,
# pyre-strict
from typing import List
def unannotated(): # Error: missing return annotation
return b"" + "" # Error: function body *is* checked
def annotated() -> List: # Error: implicit `Any` for generic parameter to `List`
any = unannotated()
any.attribute # Note: the type of `any` is still any.
return 1 # Error: returning `int` but expecting `List`
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-By-Defaultβ
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 # pyre-strict
.
When Source Code is not Availableβ
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:
# my_dynamic_module.pyi
def dynamic_function() -> int: ... # Function body is omitted
If a __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.
# my_stub.pyi
from typing import Any
foo: int = 42
# Parameter needs to be typed as `str` and return type needs to be `Any`
def __getattr__(name: str) -> Any: ...
# my_source.py
import my_stub
reveal_type(my_stub.foo) # Reveals `int`
reveal_type(my_stub.undefined) # Reveals `Any`
Typeshedβ
Strategies for Increasing Coverageβ
Pyre comes with tooling to make it easy to increase type coverage in your project.
Upgradeβ
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 pyre-upgrade
with
(venv) $ pyre --output=json | pyre-upgrade fixme
or if you are using a local configuration
(venv) $ pyre --output=json -l <project> | pyre-upgrade fixme
Automatic Type Inferenceβ
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
(venv) $ cd <path to project>; pyre infer -i
to automatically apply annotations.
For dynamic inference we recommend you give MonkeyType a try.