CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="color-scheme" content="light dark"> <title>PEP 747 – Annotating Type Forms | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0747/"> <link rel="stylesheet" href="../_static/style.css" type="text/css"> <link rel="stylesheet" href="../_static/mq.css" type="text/css"> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light"> <link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark"> <link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss"> <meta property="og:title" content='PEP 747 – Annotating Type Forms | peps.python.org'> <meta property="og:description" content="Type expressions provide a standardized way to specify types in the Python type system. When a type expression is evaluated at runtime, the resulting type form object encodes the information supplied in the type expression. This enables a variety of use..."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0747/"> <meta property="og:site_name" content="Python Enhancement Proposals (PEPs)"> <meta property="og:image" content="https://peps.python.org/_static/og-image.png"> <meta property="og:image:alt" content="Python PEPs"> <meta property="og:image:width" content="200"> <meta property="og:image:height" content="200"> <meta name="description" content="Type expressions provide a standardized way to specify types in the Python type system. When a type expression is evaluated at runtime, the resulting type form object encodes the information supplied in the type expression. This enables a variety of use..."> <meta name="theme-color" content="#3776ab"> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all"> <title>Following system colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="9"></circle> <path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path> </svg> </symbol> <symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all"> <title>Selected dark colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path stroke="none" d="M0 0h24v24H0z" fill="none"></path> <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path> </svg> </symbol> <symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all"> <title>Selected light colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="5"></circle> <line x1="12" y1="1" x2="12" y2="3"></line> <line x1="12" y1="21" x2="12" y2="23"></line> <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> <line x1="1" y1="12" x2="3" y2="12"></line> <line x1="21" y1="12" x2="23" y2="12"></line> <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> </svg> </symbol> </svg> <script> document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto" </script> <section id="pep-page-section"> <header> <h1>Python Enhancement Proposals</h1> <ul class="breadcrumbs"> <li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li> <li><a href="../pep-0000/">PEP Index</a> » </li> <li>PEP 747</li> </ul> <button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())"> <svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg> Toggle light / dark / auto colour theme </button> </header> <article> <section id="pep-content"> <h1 class="page-title">PEP 747 – Annotating Type Forms</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">David Foster <david at dafoster.net>, Eric Traut <erictr at microsoft.com></dd> <dt class="field-even">Sponsor:</dt> <dd class="field-even">Jelle Zijlstra <jelle.zijlstra at gmail.com></dd> <dt class="field-odd">Discussions-To:</dt> <dd class="field-odd"><a class="reference external" href="https://discuss.python.org/t/pep-747-typeexpr-type-hint-for-a-type-expression/55984">Discourse thread</a></dd> <dt class="field-even">Status:</dt> <dd class="field-even"><abbr title="Proposal under active discussion and revision">Draft</abbr></dd> <dt class="field-odd">Type:</dt> <dd class="field-odd"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd> <dt class="field-even">Topic:</dt> <dd class="field-even"><a class="reference external" href="../topic/typing/">Typing</a></dd> <dt class="field-odd">Created:</dt> <dd class="field-odd">27-May-2024</dd> <dt class="field-even">Python-Version:</dt> <dd class="field-even">3.14</dd> <dt class="field-odd">Post-History:</dt> <dd class="field-odd"><a class="reference external" href="https://discuss.python.org/t/typeform-spelling-for-a-type-annotation-object-at-runtime/51435" title="Discourse thread">19-Apr-2024</a>, <a class="reference external" href="https://discuss.python.org/t/typeform-spelling-for-a-type-annotation-object-at-runtime/51435/7/" title="Discourse message">04-May-2024</a>, <a class="reference external" href="https://discuss.python.org/t/pep-747-typeexpr-type-hint-for-a-type-expression/55984" title="Discourse thread">17-Jun-2024</a></dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#motivation">Motivation</a><ul> <li><a class="reference internal" href="#why-not-type-c">Why not <code class="docutils literal notranslate">type[C]</code>?</a></li> <li><a class="reference internal" href="#typeform-use-cases">TypeForm use cases</a></li> </ul> </li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#implicit-typeform-evaluation">Implicit <code class="docutils literal notranslate">TypeForm</code> Evaluation</a></li> <li><a class="reference internal" href="#explicit-typeform-evaluation">Explicit <code class="docutils literal notranslate">TypeForm</code> Evaluation</a></li> <li><a class="reference internal" href="#assignability">Assignability</a></li> </ul> </li> <li><a class="reference internal" href="#backward-compatibility">Backward Compatibility</a></li> <li><a class="reference internal" href="#how-to-teach-this">How to Teach This</a></li> <li><a class="reference internal" href="#advanced-examples">Advanced Examples</a><ul> <li><a class="reference internal" href="#introspecting-type-form-objects">Introspecting type form objects</a></li> <li><a class="reference internal" href="#combining-with-a-type-variable">Combining with a type variable</a></li> <li><a class="reference internal" href="#combining-with-type">Combining with <code class="docutils literal notranslate">type</code></a></li> <li><a class="reference internal" href="#combining-with-typeis-and-typeguard">Combining with <code class="docutils literal notranslate">TypeIs</code> and <code class="docutils literal notranslate">TypeGuard</code></a></li> <li><a class="reference internal" href="#challenges-when-accepting-all-typeforms">Challenges When Accepting All TypeForms</a></li> </ul> </li> <li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#alternative-names">Alternative names</a></li> <li><a class="reference internal" href="#widen-type-c-to-support-all-type-expressions">Widen <code class="docutils literal notranslate">type[C]</code> to support all type expressions</a></li> <li><a class="reference internal" href="#accept-arbitrary-annotation-expressions">Accept arbitrary annotation expressions</a></li> <li><a class="reference internal" href="#pattern-matching-on-type-forms">Pattern matching on type forms</a></li> </ul> </li> <li><a class="reference internal" href="#footnotes">Footnotes</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> <a class="reference external" href="https://typing.python.org/en/latest/spec/annotations.html#type-expression" title="(in typing)">Type expressions</a> provide a standardized way to specify types in the Python type system. When a type expression is evaluated at runtime, the resulting type form object encodes the information supplied in the type expression. This enables a variety of use cases including runtime type checking, introspection, and metaprogramming. Such use cases have proliferated, but there is currently no way to accurately annotate functions that accept type form objects. Developers are forced to use an overly-wide type like <code class="docutils literal notranslate">object</code>, which makes some use cases impossible and generally reduces type safety. This PEP addresses this limitation by introducing a new special form <code class="docutils literal notranslate">typing.TypeForm</code>. This PEP makes no changes to the Python grammar. Correct usage of <code class="docutils literal notranslate">TypeForm</code> is intended to be enforced only by type checkers, not by the Python runtime. </section> <section id="motivation"> <h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2> A function that operates on type form objects must understand how type expression details are encoded in these objects. For example, <code class="docutils literal notranslate">int | str</code>, <code class="docutils literal notranslate">"int | str"</code>, <code class="docutils literal notranslate">list[int]</code>, and <code class="docutils literal notranslate">MyTypeAlias</code> are all valid type expressions, and they evaluate to instances of <code class="docutils literal notranslate">types.UnionType</code>, <code class="docutils literal notranslate">builtins.str</code>, <code class="docutils literal notranslate">types.GenericAlias</code>, and <code class="docutils literal notranslate">typing.TypeAliasType</code>, respectively. There is currently no way to indicate to a type checker that a function accepts type form objects and knows how to work with them. <code class="docutils literal notranslate">TypeForm</code> addresses this limitation. For example, here is a function that checks whether a value is assignable to a specified type and returns None if it is not: <div class="highlight-default notranslate"><div class="highlight"><pre>def trycast[T](typx: TypeForm[T], value: object) -> T | None: ... </pre></div> </div> The use of <code class="docutils literal notranslate">TypeForm</code> and the type variable <code class="docutils literal notranslate">T</code> describes a relationship between the type form passed to parameter <code class="docutils literal notranslate">typx</code> and the function’s return type. <code class="docutils literal notranslate">TypeForm</code> can also be used with <a class="reference external" href="https://typing.python.org/en/latest/spec/narrowing.html#typeis" title="(in typing)">TypeIs</a> to define custom type narrowing behaviors: <div class="highlight-default notranslate"><div class="highlight"><pre>def isassignable[T](value: object, typx: TypeForm[T]) -> TypeIs[T]: ... request_json: object = ... if isassignable(request_json, MyTypedDict): assert_type(request_json, MyTypedDict) # Type of variable is narrowed </pre></div> </div> The <code class="docutils literal notranslate">isassignable</code> function implements something like an enhanced <code class="docutils literal notranslate">isinstance</code> check. This is useful for validating whether a value decoded from JSON conforms to a particular structure of nested <code class="docutils literal notranslate">TypedDict</code>s, lists, unions, <code class="docutils literal notranslate">Literal</code>s, or any other type form that can be described with a type expression. This kind of check was alluded to in <a class="pep reference internal" href="../pep-0589/#using-typeddict-types" title="PEP 589 – TypedDict: Type Hints for Dictionaries with a Fixed Set of Keys § Using TypedDict Types">PEP 589</a> but could not be implemented without <code class="docutils literal notranslate">TypeForm</code>. <section id="why-not-type-c"> <h3><a class="toc-backref" href="#why-not-type-c" role="doc-backlink">Why not <code class="docutils literal notranslate">type[C]</code>?</a></h3> One might think that <code class="docutils literal notranslate">type[C]</code> would suffice for these use cases. However, only class objects (instances of the <code class="docutils literal notranslate">builtins.type</code> class) are assignable to <code class="docutils literal notranslate">type[C]</code>. Many type form objects do not meet this requirement: <div class="highlight-default notranslate"><div class="highlight"><pre>def trycast[T](typx: type[T], value: object) -> T | None: ... trycast(str, 'hi') # OK trycast(Literal['hi'], 'hi') # Type violation trycast(str | None, 'hi') # Type violation trycast(MyProtocolClass, obj) # Type violation </pre></div> </div> </section> <section id="typeform-use-cases"> <h3><a class="toc-backref" href="#typeform-use-cases" role="doc-backlink">TypeForm use cases</a></h3> <a class="reference external" href="https://github.com/python/mypy/issues/9773#issuecomment-2017998886">A survey of Python libraries</a> reveals several categories of functions that would benefit from <code class="docutils literal notranslate">TypeForm</code>: <ul class="simple"> <li>Assignability checkers:<ul> <li>Determines whether a value is assignable to a specified type</li> <li>Pattern 1: <code class="docutils literal notranslate">def is_assignable[T](value: object, typx: TypeForm[T]) -> TypeIs[T]</code></li> <li>Pattern 2: <code class="docutils literal notranslate">def is_match[T](value: object, typx: TypeForm[T]) -> TypeGuard[T]</code></li> <li>Examples: beartype.<a class="reference external" href="https://github.com/beartype/beartype/issues/255">is_bearable</a>, trycast.<a class="reference external" href="https://github.com/davidfstr/trycast?tab=readme-ov-file#isassignable-api">isassignable</a>, typeguard.<a class="reference external" href="https://typeguard.readthedocs.io/en/latest/api.html#typeguard.check_type">check_type</a>, xdsl.<a class="reference external" href="https://github.com/xdslproject/xdsl/blob/ac12c9ab0d64618475efb98d1d197bdd79f593c3/xdsl/utils/hints.py#L23">isa</a></li> </ul> </li> </ul> <ul> <li>Converters:<ul> <li>If a value is assignable to (or coercible to) a specified type, a converter returns the value narrowed to (or coerced to) that type. Otherwise, an exception is raised.</li> <li>Pattern 1:<div class="highlight-default notranslate"><div class="highlight"><pre>def convert[T](value: object, typx: TypeForm[T]) -> T </pre></div> </div> <ul class="simple"> <li>Examples: cattrs.BaseConverter.<a class="reference external" href="https://github.com/python-attrs/cattrs/blob/5f5c11627a7f67a23d6212bc7df9f96243c62dc5/src/cattrs/converters.py#L332-L334">structure</a>, trycast.<a class="reference external" href="https://github.com/davidfstr/trycast#checkcast-api">checkcast</a>, typedload.<a class="reference external" href="https://ltworf.github.io/typedload/">load</a></li> </ul> </li> <li>Pattern 2:<div class="highlight-default notranslate"><div class="highlight"><pre>class Converter[T]: def __init__(self, typx: TypeForm[T]) -> None: ... def convert(self, value: object) -> T: ... </pre></div> </div> <ul class="simple"> <li>Examples: pydantic.<a class="reference external" href="https://stackoverflow.com/a/61021183/604063">TypeAdapter(T).validate_python</a>, mashumaro.<a class="reference external" href="https://github.com/Fatal1ty/mashumaro?tab=readme-ov-file#usage-example">JSONDecoder(T).decode</a></li> </ul> </li> </ul> </li> </ul> <ul> <li>Typed field definitions:<ul> <li>Pattern:<div class="highlight-default notranslate"><div class="highlight"><pre>class Field[T]: value_type: TypeForm[T] </pre></div> </div> </li> <li>Examples: attrs.<a class="reference external" href="https://www.attrs.org/en/stable/api.html#attrs.make_class">make_class</a>, dataclasses.<a class="reference external" href="https://github.com/python/typeshed/issues/11653">make_dataclass</a> <a class="footnote-reference brackets" href="#dataclassinitvar" id="id1">[3]</a>, <a class="reference external" href="https://github.com/Fatal1ty/openapify/blob/c8d968c7c9c8fd7d4888bd2ddbe18ffd1469f3ca/openapify/core/models.py#L16">openapify</a></li> </ul> </li> </ul> The survey also identified some introspection functions that accept runtime type forms as input. Today, these functions are annotated with <code class="docutils literal notranslate">object</code>: <ul class="simple"> <li>General introspection operations:<ul> <li>Pattern: <code class="docutils literal notranslate">def get_annotation_info(typx: object) -> object</code></li> <li>Examples: typing.{<a class="reference external" href="https://docs.python.org/3/library/typing.html#typing.get_origin">get_origin</a>, <a class="reference external" href="https://docs.python.org/3/library/typing.html#typing.get_args">get_args</a>}, <a class="reference external" href="https://github.com/ilevkivskyi/typing_inspect?tab=readme-ov-file#readme">typing_inspect</a>.{is_*_type, get_origin, get_parameters}</li> </ul> </li> </ul> These functions accept values evaluated from arbitrary annotation expressions, not just type expressions, so they cannot be altered to use <code class="docutils literal notranslate">TypeForm</code>. </section> </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> When a type expression is evaluated at runtime, the resulting value is a type form object. This value encodes the information supplied in the type expression, and it represents the type described by that type expression. <code class="docutils literal notranslate">TypeForm</code> is a special form that, when used in a type expression, describes a set of type form objects. It accepts a single type argument, which must be a valid type expression. <code class="docutils literal notranslate">TypeForm[T]</code> describes the set of all type form objects that represent the type <code class="docutils literal notranslate">T</code> or types that are <a class="reference external" href="https://typing.python.org/en/latest/spec/glossary.html#term-assignable" title="(in typing)">assignable to</a> <code class="docutils literal notranslate">T</code>. For example, <code class="docutils literal notranslate">TypeForm[str | None]</code> describes the set of all type form objects that represent a type assignable to <code class="docutils literal notranslate">str | None</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>ok1: TypeForm[str | None] = str | None # OK ok2: TypeForm[str | None] = str # OK ok3: TypeForm[str | None] = None # OK ok4: TypeForm[str | None] = Literal[None] # OK ok5: TypeForm[str | None] = Optional[str] # OK ok6: TypeForm[str | None] = "str | None" # OK ok7: TypeForm[str | None] = Any # OK err1: TypeForm[str | None] = str | int # Error err2: TypeForm[str | None] = list[str | None] # Error </pre></div> </div> By this same definition, <code class="docutils literal notranslate">TypeForm[object]</code> describes a type form object that represents the type <code class="docutils literal notranslate">object</code> or any type that is assignable to <code class="docutils literal notranslate">object</code>. Since all types in the Python type system are assignable to <code class="docutils literal notranslate">object</code>, <code class="docutils literal notranslate">TypeForm[object]</code> describes the set of all type form objects evaluated from all valid type expressions. <code class="docutils literal notranslate">TypeForm[Any]</code> describes a <code class="docutils literal notranslate">TypeForm</code> type whose type argument is not statically known but is a valid type form object. It is thus assignable both to and from any other <code class="docutils literal notranslate">TypeForm</code> type (because <code class="docutils literal notranslate">Any</code> is assignable both to and from any type). The type expression <code class="docutils literal notranslate">TypeForm</code>, with no type argument provided, is equivalent to <code class="docutils literal notranslate">TypeForm[Any]</code>. <section id="implicit-typeform-evaluation"> <h3><a class="toc-backref" href="#implicit-typeform-evaluation" role="doc-backlink">Implicit <code class="docutils literal notranslate">TypeForm</code> Evaluation</a></h3> When a static type checker encounters an expression that follows all of the syntactic, semantic and contextual rules for a type expression as detailed in the typing spec, the evaluated type of this expression should be assignable to <code class="docutils literal notranslate">TypeForm[T]</code> if the type it describes is assignable to <code class="docutils literal notranslate">T</code>. For example, if a static type checker encounters the expression <code class="docutils literal notranslate">str | None</code>, it may normally evaluate its type as <code class="docutils literal notranslate">UnionType</code> because it produces a runtime value that is an instance of <code class="docutils literal notranslate">types.UnionType</code>. However, because this expression is a valid type expression, it is also assignable to the type <code class="docutils literal notranslate">TypeForm[str | None]</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>v1_actual: UnionType = str | None # OK v1_type_form: TypeForm[str | None] = str | None # OK v2_actual: type = list[int] # OK v2_type_form: TypeForm = list[int] # OK </pre></div> </div> The <code class="docutils literal notranslate">Annotated</code> special form is allowed in type expressions, so it can also appear in an expression that is assignable to <code class="docutils literal notranslate">TypeForm</code>. Consistent with the typing spec’s rules for <code class="docutils literal notranslate">Annotated</code>, a static type checker may choose to ignore any <code class="docutils literal notranslate">Annotated</code> metadata that it does not understand: <div class="highlight-default notranslate"><div class="highlight"><pre>v3: TypeForm[int | str] = Annotated[int | str, "metadata"] # OK v4: TypeForm[Annotated[int | str, "metadata"]] = int | str # OK </pre></div> </div> A string literal expression containing a valid type expression should likewise be assignable to <code class="docutils literal notranslate">TypeForm</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>v5: TypeForm[set[str]] = "set[str]" # OK </pre></div> </div> The typing spec defines syntactic rules for type expressions in the form of a <a class="reference external" href="https://typing.python.org/en/latest/spec/annotations.html#expression-grammar" title="(in typing)">formal grammar</a>. Semantic rules are specified as comments along with the grammar definition. Contextual requirements are detailed throughout the typing spec in sections that discuss concepts that appear within type expressions. For example, the special form <code class="docutils literal notranslate">Self</code> can be used in a type expression only within a class, and a type variable can be used within a type expression only when it is associated with a valid scope. Expressions that violate one or more of the syntactic, semantic, or contextual rules for type expressions should not evaluate to a <code class="docutils literal notranslate">TypeForm</code> type.: <div class="highlight-default notranslate"><div class="highlight"><pre>bad1: TypeForm = tuple() # Error: Call expression not allowed in type expression bad2: TypeForm = (1, 2) # Error: Tuple expression not allowed in type expression bad3: TypeForm = 1 # Non-class object not allowed in type expression bad4: TypeForm = Self # Error: Self not allowed outside of a class bad5: TypeForm = Literal[var] # Error: Variable not allowed in type expression bad6: TypeForm = Literal[f""] # Error: f-strings not allowed in type expression bad7: TypeForm = ClassVar[int] # Error: ClassVar not allowed in type expression bad8: TypeForm = Required[int] # Error: Required not allowed in type expression bad9: TypeForm = Final[int] # Error: Final not allowed in type expression bad10: TypeForm = Unpack[Ts] # Error: Unpack not allowed in this context bad11: TypeForm = Optional # Error: Invalid use of Optional special form bad12: TypeForm = T # Error if T is an out-of-scope TypeVar bad13: TypeForm = "int + str" # Error: invalid quoted type expression </pre></div> </div> </section> <section id="explicit-typeform-evaluation"> <h3><a class="toc-backref" href="#explicit-typeform-evaluation" role="doc-backlink">Explicit <code class="docutils literal notranslate">TypeForm</code> Evaluation</a></h3> <code class="docutils literal notranslate">TypeForm</code> also acts as a function that can be called with a single argument. Type checkers should validate that this argument is a valid type expression: <div class="highlight-default notranslate"><div class="highlight"><pre>x1 = TypeForm(str | None) reveal_type(v1) # Revealed type is "TypeForm[str | None]" x2 = TypeForm("list[int]") revealed_type(v2) # Revealed type is "TypeForm[list[int]]" x3 = TypeForm('type(1)') # Error: invalid type expression </pre></div> </div> At runtime the <code class="docutils literal notranslate">TypeForm(...)</code> callable simply returns the value passed to it. This explicit syntax serves two purposes. First, it documents the developer’s intent to use the value as a type form object. Second, static type checkers validate that all rules for type expressions are followed: <div class="highlight-default notranslate"><div class="highlight"><pre>x4 = type(1) # No error, evaluates to "type[int]" x5 = TypeForm(type(1)) # Error: call not allowed in type expression </pre></div> </div> </section> <section id="assignability"> <h3><a class="toc-backref" href="#assignability" role="doc-backlink">Assignability</a></h3> <code class="docutils literal notranslate">TypeForm</code> has a single type parameter, which is covariant. That means <code class="docutils literal notranslate">TypeForm[B]</code> is assignable to <code class="docutils literal notranslate">TypeForm[A]</code> if <code class="docutils literal notranslate">B</code> is assignable to <code class="docutils literal notranslate">A</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>def get_type_form() -> TypeForm[int]: ... t1: TypeForm[int | str] = get_type_form() # OK t2: TypeForm[str] = get_type_form() # Error </pre></div> </div> <code class="docutils literal notranslate">type[T]</code> is a subtype of <code class="docutils literal notranslate">TypeForm[T]</code>, which means that <code class="docutils literal notranslate">type[B]</code> is assignable to <code class="docutils literal notranslate">TypeForm[A]</code> if <code class="docutils literal notranslate">B</code> is assignable to <code class="docutils literal notranslate">A</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>def get_type() -> type[int]: ... t3: TypeForm[int | str] = get_type() # OK t4: TypeForm[str] = get_type() # Error </pre></div> </div> <code class="docutils literal notranslate">TypeForm</code> is a subtype of <code class="docutils literal notranslate">object</code> and is assumed to have all of the attributes and methods of <code class="docutils literal notranslate">object</code>. </section> </section> <section id="backward-compatibility"> <h2><a class="toc-backref" href="#backward-compatibility" role="doc-backlink">Backward Compatibility</a></h2> This PEP clarifies static type checker behaviors when evaluating type expressions in “value expression” contexts (that is, contexts where type expressions are not mandated by the typing spec). In the absence of a <code class="docutils literal notranslate">TypeForm</code> type annotation, existing type evaluation behaviors persist, so no backward compatibility issues are anticipated. For example, if a static type checker previously evaluated the type of expression <code class="docutils literal notranslate">str | None</code> as <code class="docutils literal notranslate">UnionType</code>, it will continue to do so unless this expression is assigned to a variable or parameter whose type is annotated as <code class="docutils literal notranslate">TypeForm</code>. </section> <section id="how-to-teach-this"> <h2><a class="toc-backref" href="#how-to-teach-this" role="doc-backlink">How to Teach This</a></h2> Type expressions are used in annotations to describe which values are accepted by a function parameter, returned by a function, or stored in a variable: <div class="highlight-text notranslate"><div class="highlight"><pre> parameter type return type | | v v def plus(n1: int, n2: int) -> int: sum: int = n1 + n2 ^ | variable type return sum </pre></div> </div> Type expressions evaluate to valid type form objects at runtime and can be assigned to variables and manipulated like any other data in a program: <div class="highlight-text notranslate"><div class="highlight"><pre> a variable a type expression | | v v int_type_form: TypeForm = int | None ^ | the type of a type form object </pre></div> </div> <code class="docutils literal notranslate">TypeForm[]</code> is how you spell the type of a type form object, which is a runtime representation of a type. <code class="docutils literal notranslate">TypeForm</code> is similar to <code class="docutils literal notranslate">type</code>, but <code class="docutils literal notranslate">type</code> is compatible only with class objects like <code class="docutils literal notranslate">int</code>, <code class="docutils literal notranslate">str</code>, <code class="docutils literal notranslate">list</code>, or <code class="docutils literal notranslate">MyClass</code>. <code class="docutils literal notranslate">TypeForm</code> accommodates any type form that can be expressed using a valid type expression, including those with brackets (<code class="docutils literal notranslate">list[int]</code>), union operators (<code class="docutils literal notranslate">int | None</code>), and special forms (<code class="docutils literal notranslate">Any</code>, <code class="docutils literal notranslate">LiteralString</code>, <code class="docutils literal notranslate">Never</code>, etc.). Most programmers will not define their own functions that accept a <code class="docutils literal notranslate">TypeForm</code> parameter or return a <code class="docutils literal notranslate">TypeForm</code> value. It is more common to pass a type form object to a library function that knows how to decode and use such objects. For example, the <code class="docutils literal notranslate">isassignable</code> function in the <code class="docutils literal notranslate">trycast</code> library can be used like Python’s built-in <code class="docutils literal notranslate">isinstance</code> function to check whether a value matches the shape of a particular type. <code class="docutils literal notranslate">isassignable</code> accepts any type form object as input. <ul> <li>Yes:<div class="highlight-default notranslate"><div class="highlight"><pre>from trycast import isassignable if isassignable(some_object, MyTypedDict): # OK: MyTypedDict is a TypeForm[] ... </pre></div> </div> </li> <li>No:<div class="highlight-default notranslate"><div class="highlight"><pre>if isinstance(some_object, MyTypedDict): # ERROR: MyTypedDict is not a type[] ... </pre></div> </div> </li> </ul> </section> <section id="advanced-examples"> <h2><a class="toc-backref" href="#advanced-examples" role="doc-backlink">Advanced Examples</a></h2> If you want to write your own runtime type checker or a function that manipulates type form objects as values at runtime, this section provides examples of how such a function can use <code class="docutils literal notranslate">TypeForm</code>. <section id="introspecting-type-form-objects"> <h3><a class="toc-backref" href="#introspecting-type-form-objects" role="doc-backlink">Introspecting type form objects</a></h3> Functions like <code class="docutils literal notranslate">typing.get_origin</code> and <code class="docutils literal notranslate">typing.get_args</code> can be used to extract components of some type form objects. <div class="highlight-default notranslate"><div class="highlight"><pre>import typing from typing import TypeForm, cast def strip_annotated_metadata[T](typx: TypeForm[T]) -> TypeForm[T]: if typing.get_origin(typx) is typing.Annotated: typx = cast(TypeForm[T], typing.get_args(typx)[0]) return typx </pre></div> </div> <code class="docutils literal notranslate">isinstance</code> and <code class="docutils literal notranslate">is</code> can also be used to distinguish between different kinds of type form objects: <div class="highlight-default notranslate"><div class="highlight"><pre>import types import typing from typing import TypeForm, cast def split_union(typx: TypeForm) -> tuple[TypeForm, ...]: if isinstance(typx, types.UnionType): # X | Y return cast(tuple[TypeForm, ...], typing.get_args(typx)) if typing.get_origin(typx) is typing.Union: # Union[X, Y] return cast(tuple[TypeForm, ...], typing.get_args(typx)) if typx in (typing.Never, typing.NoReturn,): return () return (typx,) </pre></div> </div> </section> <section id="combining-with-a-type-variable"> <h3><a class="toc-backref" href="#combining-with-a-type-variable" role="doc-backlink">Combining with a type variable</a></h3> <code class="docutils literal notranslate">TypeForm</code> can be parameterized by a type variable that is used elsewhere within the same function definition: <div class="highlight-default notranslate"><div class="highlight"><pre>def as_instance[T](typx: TypeForm[T]) -> T | None: return typx() if isinstance(typx, type) else None </pre></div> </div> </section> <section id="combining-with-type"> <h3><a class="toc-backref" href="#combining-with-type" role="doc-backlink">Combining with <code class="docutils literal notranslate">type</code></a></h3> Both <code class="docutils literal notranslate">TypeForm</code> and <code class="docutils literal notranslate">type</code> can be parameterized by the same type variable within the same function definition: <div class="highlight-default notranslate"><div class="highlight"><pre>def as_type[T](typx: TypeForm[T]) -> type[T] | None: return typx if isinstance(typx, type) else None </pre></div> </div> </section> <section id="combining-with-typeis-and-typeguard"> <h3><a class="toc-backref" href="#combining-with-typeis-and-typeguard" role="doc-backlink">Combining with <code class="docutils literal notranslate">TypeIs</code> and <code class="docutils literal notranslate">TypeGuard</code></a></h3> A type variable can also be used by a <code class="docutils literal notranslate">TypeIs</code> or <code class="docutils literal notranslate">TypeGuard</code> return type: <div class="highlight-default notranslate"><div class="highlight"><pre>def isassignable[T](value: object, typx: TypeForm[T]) -> TypeIs[T]: ... count: int | str = ... if isassignable(count, int): assert_type(count, int) else: assert_type(count, str) </pre></div> </div> </section> <section id="challenges-when-accepting-all-typeforms"> <h3><a class="toc-backref" href="#challenges-when-accepting-all-typeforms" role="doc-backlink">Challenges When Accepting All TypeForms</a></h3> A function that takes an arbitrary <code class="docutils literal notranslate">TypeForm</code> as input must support a variety of possible type form objects. Such functions are not easy to write. <ul class="simple"> <li>New special forms are introduced with each new Python version, and special handling may be required for each one.</li> <li>Quoted annotations <a class="footnote-reference brackets" href="#quoted-less-common" id="id2">[5]</a> (like <code class="docutils literal notranslate">'list[str]'</code>) must be parsed (to something like <code class="docutils literal notranslate">list[str]</code>).</li> <li>Resolving quoted forward references inside type expressions is typically done with <code class="docutils literal notranslate">eval()</code>, which is difficult to use in a safe way.</li> <li>Recursive types like <code class="docutils literal notranslate">IntTree = list[int | 'IntTree']</code> are difficult to resolve.</li> <li>User-defined generic types (like Django’s <code class="docutils literal notranslate">QuerySet[User]</code>) can introduce non-standard behaviors that require runtime support.</li> </ul> </section> </section> <section id="reference-implementation"> <h2><a class="toc-backref" href="#reference-implementation" role="doc-backlink">Reference Implementation</a></h2> Pyright (version 1.1.379) provides a reference implementation for <code class="docutils literal notranslate">TypeForm</code>. Mypy contributors also <a class="reference external" href="https://github.com/python/mypy/issues/9773">plan to implement</a> support for <code class="docutils literal notranslate">TypeForm</code>. A reference implementation of the runtime component is provided in the <code class="docutils literal notranslate">typing_extensions</code> module. </section> <section id="rejected-ideas"> <h2><a class="toc-backref" href="#rejected-ideas" role="doc-backlink">Rejected Ideas</a></h2> <section id="alternative-names"> <h3><a class="toc-backref" href="#alternative-names" role="doc-backlink">Alternative names</a></h3> Alternate names were considered for <code class="docutils literal notranslate">TypeForm</code>. <code class="docutils literal notranslate">TypeObject</code> and <code class="docutils literal notranslate">TypeType</code> were deemed too generic. <code class="docutils literal notranslate">TypeExpression</code> and <code class="docutils literal notranslate">TypeExpr</code> were also considered, but these were considered confusing because these objects are not themselves “expressions” but rather the result of evaluating a type expression. </section> <section id="widen-type-c-to-support-all-type-expressions"> <h3><a class="toc-backref" href="#widen-type-c-to-support-all-type-expressions" role="doc-backlink">Widen <code class="docutils literal notranslate">type[C]</code> to support all type expressions</a></h3> <code class="docutils literal notranslate">type</code> was <a class="reference external" href="https://mail.python.org/archives/list/typing-sig@python.org/message/D5FHORQVPHX3BHUDGF3A3TBZURBXLPHD/">designed</a> to describe class objects, subclasses of the <code class="docutils literal notranslate">type</code> class. A value with the type <code class="docutils literal notranslate">type</code> is assumed to be instantiable through a constructor call. Widening the meaning of <code class="docutils literal notranslate">type</code> to represent arbitrary type form objects would present backward compatibility problems and would eliminate a way to describe the set of values limited to subclasses of <code class="docutils literal notranslate">type</code>. </section> <section id="accept-arbitrary-annotation-expressions"> <h3><a class="toc-backref" href="#accept-arbitrary-annotation-expressions" role="doc-backlink">Accept arbitrary annotation expressions</a></h3> Certain special forms act as type qualifiers and can be used in some but not all annotation contexts: For example. the type qualifier <code class="docutils literal notranslate">Final</code> can be used as a variable type but not as a parameter type or a return type: <div class="highlight-default notranslate"><div class="highlight"><pre>some_const: Final[str] = ... # OK def foo(not_reassignable: Final[object]): ... # Error: Final not allowed here def nonsense() -> Final[object]: ... # Error: Final not allowed here </pre></div> </div> With the exception of <code class="docutils literal notranslate">Annotated</code>, type qualifiers are not allowed in type expressions. <code class="docutils literal notranslate">TypeForm</code> is limited to type expressions because its assignability rules are based on the assignability rules for types. It is nonsensical to ask whether <code class="docutils literal notranslate">Final[int]</code> is assignable to <code class="docutils literal notranslate">int</code> because the former is not a valid type expression. Functions that wish to operate on objects that are evaluated from annotation expressions can continue to accept such inputs as <code class="docutils literal notranslate">object</code> parameters. </section> <section id="pattern-matching-on-type-forms"> <h3><a class="toc-backref" href="#pattern-matching-on-type-forms" role="doc-backlink">Pattern matching on type forms</a></h3> It was asserted that some functions may wish to pattern match on the interior of type expressions in their signatures. One use case is to allow a function to explicitly enumerate all the specific kinds of type expressions it supports as input. Consider the following possible pattern matching syntax: <div class="highlight-default notranslate"><div class="highlight"><pre>@overload def checkcast(typx: TypeForm[AT=Annotated[T, *A]], value: str) -> T: ... @overload def checkcast(typx: TypeForm[UT=Union[*Ts]], value: str) -> Union[*Ts]: ... @overload def checkcast(typx: type[C], value: str) -> C: ... # ... (more) </pre></div> </div> All functions observed in the wild that conceptually accept type form objects generally try to support all kinds of type expressions, so it doesn’t seem valuable to enumerate a particular subset. Additionally, the above syntax isn’t precise enough to fully describe the input constraints for a typical function in the wild. For example, many functions do not support type expressions with quoted subexpressions like <code class="docutils literal notranslate">list['Movie']</code>. A second use case for pattern matching is to explicitly match an <code class="docutils literal notranslate">Annotated</code> form to extract the interior type argument and strip away any metadata: <div class="highlight-default notranslate"><div class="highlight"><pre>def checkcast( typx: TypeForm[T] | TypeForm[AT=Annotated[T, *A]], value: object ) -> T: </pre></div> </div> However, <code class="docutils literal notranslate">Annotated[T, metadata]</code> is already treated equivalent to <code class="docutils literal notranslate">T</code> by static type checkers. There’s no additional value in being explicit about this behavior. The example above could more simply be written as the equivalent: <div class="highlight-default notranslate"><div class="highlight"><pre>def checkcast(typx: TypeForm[T], value: object) -> T: </pre></div> </div> </section> </section> <section id="footnotes"> <h2><a class="toc-backref" href="#footnotes" role="doc-backlink">Footnotes</a></h2> <aside class="footnote-list brackets"> <aside class="footnote brackets" id="type-t" role="doc-footnote"> <dt class="label" id="type-t">[1]</dt> <dd><a class="reference external" href="https://typing.python.org/en/latest/spec/special-types.html#type-brackets" title="(in typing)">Type[T]</a> spells a class object</aside> <aside class="footnote brackets" id="typeis" role="doc-footnote"> <dt class="label" id="typeis">[2]</dt> <dd><a class="reference external" href="https://typing.python.org/en/latest/spec/narrowing.html#typeis" title="(in typing)">TypeIs[T]</a> is similar to bool</aside> <aside class="footnote brackets" id="dataclassinitvar" role="doc-footnote"> <dt class="label" id="dataclassinitvar">[<a href="#id1">3</a>]</dt> <dd><code class="docutils literal notranslate">dataclass.make_dataclass</code> allows the type qualifier <code class="docutils literal notranslate">InitVar[...]</code>, so <code class="docutils literal notranslate">TypeForm</code> cannot be used in this case.</aside> <aside class="footnote brackets" id="forward-ref-normalization" role="doc-footnote"> <dt class="label" id="forward-ref-normalization">[4]</dt> <dd>Special forms normalize string arguments to <code class="docutils literal notranslate">ForwardRef</code> instances at runtime using internal helper functions in the <code class="docutils literal notranslate">typing</code> module. Runtime type checkers may wish to implement similar functions when working with string-based forward references.</aside> <aside class="footnote brackets" id="quoted-less-common" role="doc-footnote"> <dt class="label" id="quoted-less-common">[<a href="#id2">5</a>]</dt> <dd>Quoted annotations are expected to become less common starting in Python 3.14 when <a class="pep reference internal" href="../pep-0649/" title="PEP 649 – Deferred Evaluation Of Annotations Using Descriptors">deferred annotations</a> is implemented. However, code written for earlier Python versions relies on quoted annotations and will need to be supported for several years.</aside> </aside> </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. </section> </section> <hr class="docutils" /> Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0747.rst">https://github.com/python/peps/blob/main/peps/pep-0747.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0747.rst">2025-02-14 00:27:46 GMT</a> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#motivation">Motivation</a><ul> <li><a class="reference internal" href="#why-not-type-c">Why not <code class="docutils literal notranslate">type[C]</code>?</a></li> <li><a class="reference internal" href="#typeform-use-cases">TypeForm use cases</a></li> </ul> </li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#implicit-typeform-evaluation">Implicit <code class="docutils literal notranslate">TypeForm</code> Evaluation</a></li> <li><a class="reference internal" href="#explicit-typeform-evaluation">Explicit <code class="docutils literal notranslate">TypeForm</code> Evaluation</a></li> <li><a class="reference internal" href="#assignability">Assignability</a></li> </ul> </li> <li><a class="reference internal" href="#backward-compatibility">Backward Compatibility</a></li> <li><a class="reference internal" href="#how-to-teach-this">How to Teach This</a></li> <li><a class="reference internal" href="#advanced-examples">Advanced Examples</a><ul> <li><a class="reference internal" href="#introspecting-type-form-objects">Introspecting type form objects</a></li> <li><a class="reference internal" href="#combining-with-a-type-variable">Combining with a type variable</a></li> <li><a class="reference internal" href="#combining-with-type">Combining with <code class="docutils literal notranslate">type</code></a></li> <li><a class="reference internal" href="#combining-with-typeis-and-typeguard">Combining with <code class="docutils literal notranslate">TypeIs</code> and <code class="docutils literal notranslate">TypeGuard</code></a></li> <li><a class="reference internal" href="#challenges-when-accepting-all-typeforms">Challenges When Accepting All TypeForms</a></li> </ul> </li> <li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#alternative-names">Alternative names</a></li> <li><a class="reference internal" href="#widen-type-c-to-support-all-type-expressions">Widen <code class="docutils literal notranslate">type[C]</code> to support all type expressions</a></li> <li><a class="reference internal" href="#accept-arbitrary-annotation-expressions">Accept arbitrary annotation expressions</a></li> <li><a class="reference internal" href="#pattern-matching-on-type-forms">Pattern matching on type forms</a></li> </ul> </li> <li><a class="reference internal" href="#footnotes">Footnotes</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0747.rst">Page Source (GitHub)</a> </nav> </section> <script src="../_static/colour_scheme.js"></script> <script src="../_static/wrap_tables.js"></script> <script src="../_static/sticky_banner.js"></script> </body> </html>