See Also

External beartype resources include:

Related type-checking resources include:

Runtime Type Checkers

Runtime type checkers (i.e., third-party Python packages dynamically validating callables annotated by type hints at runtime, typically via decorators, function calls, and import hooks) include:

package

active

PEP-compliant

time multiplier [1]

beartype

yes

yes

1 ✕ beartype

enforce

no

yes

unknown

enforce_typing

no

yes

unknown

pydantic

yes

no

unknown

pytypes

no

yes

unknown

typeen

no

no

unknown

typical

yes

yes

unknown

typeguard

no

yes

20 ✕ beartype

Like static type checkers, runtime type checkers always require callables to be annotated by type hints. Unlike static type checkers, runtime type checkers do not necessarily comply with community standards; although some do require callers to annotate callables with strictly PEP-compliant type hints, others permit or even require callers to annotate callables with PEP-noncompliant type hints. Runtime type checkers that do so violate:

Runtime Data Validators

Runtime data validators (i.e., third-party Python packages dynamically validating callables decorated by caller-defined contracts, constraints, and validation routines at runtime) include:

Unlike both runtime type checkers and static type checkers, most runtime data validators do not require callables to be annotated by type hints. Like some runtime type checkers, most runtime data validators do not comply with community standards but instead require callers to either:

  • Decorate callables with package-specific decorators.

  • Annotate callables with package-specific and thus PEP-noncompliant type hints.

Static Type Checkers

Static type checkers (i.e., third-party tooling validating Python callable and/or variable types across an application stack at static analysis time rather than Python runtime) include:

  • mypy, Python’s official static type checker.

  • Pyre, published by Meta. …yah.

  • pyright, published by Microsoft.

  • pytype, published by Google.