Support

This page lists the Python versions and features supported by the latest version of pytype.

• Support
  • Python Version
  • Features
    • Core
    • Typing
    • Non-Standard {#non_standard_features}
    • Experimental {#experiments}
      • Ellipsis Annotation {#experimental_pytype_ellipsis_annotation}
    • Third-Party Libraries

Python Version

• Analyzes: Whether pytype can analyze code written for this version. For deprecated versions, the last pytype release that supports this version.
• Runs In: Whether pytype itself can run in this version. For deprecated versions, the last pytype release that supports this version.
• Issue: Tracking issue for dropping support (older versions) or adding it (upcoming versions), if applicable

Version	Analyzes	Runs In	Issue
2.7	2021.08.03	2020.04.01	#545
3.5	2021.09.09	2020.10.08	#677
3.6	2022.01.05	2022.01.05
3.7	2023.06.16	2023.06.16
3.8	✅	✅
3.9	✅	✅
3.10	✅	✅
3.11	✅	✅
3.12	❌	❌

Features

• Supports: ✅ (yes), ❌ (no), or 🟡 (partial)
• Issues: Notable issue(s), if applicable

Core

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.

Feature	Supports	Issues
Control Flow Analysis (“Type Narrowing”)	✅
collections.namedtuple	✅
Dataclasses	✅
Enums	✅

Typing

Feature	Version	Supports	Issues
PEP 484 – Type Hints	3.5	✅
PEP 526 – Syntax for Variable Annotations	3.6	✅
PEP 561 – Distributing and Packaging Type Information	3.7	❌	#151
PEP 563 – Postponed Evaluation of Annotations	3.7	✅
PEP 544 – Protocols	3.8	✅
PEP 586 – Literal Types	3.8	✅
PEP 589 – TypedDict	3.8	✅
PEP 591 – Adding a Final Qualifier to Typing	3.8	✅
PEP 585 – Type Hinting Generics in Standard Collections	3.9	✅
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 647 – User-Defined Type Guards	3.10	✅
PEP 646 – Variadic Generics	3.11	❌	#1525
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	❌	#1552
PEP 681 – Data Class Transforms	3.11	🟡	#1553
PEP 692 – Using TypedDict for more precise **kwargs typing	3.12	❌	#1558
PEP 695 – Type Parameter Syntax	3.12	❌
PEP 698 – Override Decorator for Static Typing	3.12	✅
PEP 696 – Type Defaults for Type Parameters	3.13	❌	#1597
PEP 702 – Marking deprecations using the type system	3.13	❌
PEP 705 – TypedDict: Read-only items	3.13	❌
PEP 742 – Narrowing types with TypeIs	3.13	✅
Custom Recursive Types	3.6	✅
Generic Type Aliases	3.6	✅
Type Annotation Inheritance	3.6	❌	#81

Non-Standard

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.

• Pytype forbids str from matching an iterable of strs, in order to catch a common accidental string iteration bug (FAQ entry).
• pytype_extensions: The pytype_extensions namespace contains many useful extensions, mostly user-contributed. The best way to learn about them is to read the inline documentation.
• Pytype allows type-annotated variables to be assigned to None or ... without including the relevant type in the type annotation. For example, x: str = None and x: str = ... are allowed. This makes it easier to type-annotate code that uses None or ... to indicate an unset value.

Experimental

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.

Ellipsis Annotation

• Start date: Jan 2022
• End date: 2024
• Reference: feature request and discussion

• 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 annotated as ... may even be inferred as Any, effectively locally disabling type analysis.

  Warning: using ... 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.

Third-Party Libraries

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.

Feature	Supports	Issues
Attrs	✅
Chex	🟡	Google-internal
Flax	🟡	Google-internal
Numpy	🟡	Minimal type stub
Tensorflow	🟡	Minimal, Google-internal