This page lists the Python versions and features supported by the latest version of pytype.
Note: pytype supports all language and stdlib features in its supported versions unless noted otherwise. This section lists features that are difficult to type for which pytype has or intends to add custom support.
|PEP 484 – Type Hints||3.5||✅|
|PEP 526 – Syntax for Variable Annotations||3.6||✅|
|PEP 544 – Protocols||3.8||✅|
|PEP 561 – Distributing and Packaging Type Information||3.7||❌||#151|
|PEP 563 – Postponed Evaluation of Annotations||3.7||✅|
|PEP 585 – Type Hinting Generics in Standard Collections||3.9||✅|
|PEP 586 – Literal Types||3.8||✅|
|PEP 589 – TypedDict||3.8||✅|
|PEP 591 – Adding a Final Qualifier to Typing||3.8||✅|
|PEP 593 – Flexible Function and Variable Annotations||3.9||✅|
|PEP 604 – Allow Writing Union Types as X | Y||3.10||✅|
|PEP 612 – Parameter Specification Variables||3.10||🟡||#786|
|PEP 613 – Explicit Type Aliases||3.10||✅|
|PEP 646 – Variadic Generics||3.11||❌||#1525|
|PEP 647 – User-Defined Type Guards||3.10||✅|
|PEP 655 – Marking individual TypedDict items as required or potentially-missing||3.11||❌|
|PEP 673 – Self Type||3.11||✅|
|PEP 675 – Arbitrary Literal String Type||3.11||❌|
|PEP 681 – Data Class Transforms||3.11||🟡|
|PEP 695 – Type Parameter Syntax||3.12||❌|
|PEP 698 – Override Decorator for Static Typing||3.12||✅|
|Custom Recursive Types||3.6||✅|
|Generic Type Aliases||3.6||✅|
|Type Annotation Inheritance||3.6||❌||#81|
This section describes notable non-standard features supported by pytype.
Note: This is not and does not endeavor to be an exhaustive list of the ways in which pytype differs from other Python type checkers. See the Pytype Typing FAQ for more on that topic.
strfrom matching an iterable of
strs, in order to catch a common accidental string iteration bug (FAQ entry).
pytype_extensionsnamespace contains many useful extensions, mostly user-contributed. The best way to learn about them is to read the inline documentation.
...without including the relevant type in the type annotation. For example,
x: str = Noneand
x: str = ...are allowed. This makes it easier to type-annotate code that uses
...to indicate an unset value.
This section describes short-lived experimental features that pytype is trialing which aren’t part of the typing spec. In general, experiments are confined to the non-opensourced parts of the Google codebase since they are not supported by other type-checking systems.
By default, experiments have a maximum lifetime of 24 months. They will then either be incorporated into a widely accepted, non-Google only standard or reverted. In either case, our team will be responsible for any remaining code cleanups. The lifetime of an experiment may be extended if forward progress toward adoption by the wider typing community is shown.
Details: Pytype allows
... as a top-level annotation. When used this way,
... means “inferred type”.
For example, when you use
... as the annotation for a function’s return
type, the type will be inferred from the function body:
def f() -> ...: # return type inferred as `int` return 0
For a variable annotation, the type will be inferred from the assignment:
_X: ... = 0 # type of `_X` inferred as `int`
Note: pytype does not guarantee any particular inference strategy. Types
... may even be inferred as
Any, effectively locally
disabling type analysis.
... as a top-level annotation is an experimental feature
that is supported only by pytype. Do not use it on any code that is
opensourced. Other type checkers such as mypy, pyright, and pycharm will
consider this annotation to be an error since it is an experiment and is not
part of the current language standard.
Note: This section does not list all third-party libraries that pytype supports, only the ones that are difficult to type for which pytype has or intends to add custom support.
|Numpy||🟡||Minimal type stub|