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 695 – Type Parameter Syntax | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0695/"> <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 695 – Type Parameter Syntax | peps.python.org'> <meta property="og:description" content="This PEP specifies an improved syntax for specifying type parameters within a generic class, function, or type alias. It also introduces a new statement for declaring type aliases."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0695/"> <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="This PEP specifies an improved syntax for specifying type parameters within a generic class, function, or type alias. It also introduces a new statement for declaring type aliases."> <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 695</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 695 – Type Parameter Syntax</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Eric Traut <erictr at microsoft.com></dd> <dt class="field-even">Sponsor:</dt> <dd class="field-even">Guido van Rossum <guido at python.org></dd> <dt class="field-odd">Discussions-To:</dt> <dd class="field-odd"><a class="reference external" href="https://mail.python.org/archives/list/typing-sig@python.org/thread/BB2BGYJY2YG5IWESKGTAPUQL3N27ZKVW/">Typing-SIG thread</a></dd> <dt class="field-even">Status:</dt> <dd class="field-even"><abbr title="Accepted and implementation complete, or no longer active">Final</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">15-Jun-2022</dd> <dt class="field-even">Python-Version:</dt> <dd class="field-even">3.12</dd> <dt class="field-odd">Post-History:</dt> <dd class="field-odd"><a class="reference external" href="https://mail.python.org/archives/list/typing-sig@python.org/thread/BB2BGYJY2YG5IWESKGTAPUQL3N27ZKVW/" title="Typing-SIG thread">20-Jun-2022</a>, <a class="reference external" href="https://discuss.python.org/t/pep-695-type-parameter-syntax/21646" title="Discourse thread">04-Dec-2022</a></dd> <dt class="field-even">Resolution:</dt> <dd class="field-even"><a class="reference external" href="https://discuss.python.org/t/pep-695-type-parameter-syntax/21646/92">Discourse message</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="#points-of-confusion">Points of Confusion</a></li> </ul> </li> <li><a class="reference internal" href="#summary-examples">Summary Examples</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#type-parameter-declarations">Type Parameter Declarations</a></li> <li><a class="reference internal" href="#upper-bound-specification">Upper Bound Specification</a></li> <li><a class="reference internal" href="#constrained-type-specification">Constrained Type Specification</a></li> <li><a class="reference internal" href="#runtime-representation-of-bounds-and-constraints">Runtime Representation of Bounds and Constraints</a></li> <li><a class="reference internal" href="#generic-type-alias">Generic Type Alias</a></li> <li><a class="reference internal" href="#runtime-type-alias-class">Runtime Type Alias Class</a></li> <li><a class="reference internal" href="#type-parameter-scopes">Type Parameter Scopes</a></li> <li><a class="reference internal" href="#accessing-type-parameters-at-runtime">Accessing Type Parameters at Runtime</a></li> <li><a class="reference internal" href="#variance-inference">Variance Inference</a></li> <li><a class="reference internal" href="#auto-variance-for-typevar">Auto Variance For TypeVar</a></li> <li><a class="reference internal" href="#compatibility-with-traditional-typevars">Compatibility with Traditional TypeVars</a></li> </ul> </li> <li><a class="reference internal" href="#runtime-implementation">Runtime Implementation</a><ul> <li><a class="reference internal" href="#grammar-changes">Grammar Changes</a></li> <li><a class="reference internal" href="#ast-changes">AST Changes</a></li> <li><a class="reference internal" href="#lazy-evaluation">Lazy Evaluation</a></li> <li><a class="reference internal" href="#scoping-behavior">Scoping Behavior</a></li> <li><a class="reference internal" href="#library-changes">Library Changes</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="#prefix-clause">Prefix Clause</a></li> <li><a class="reference internal" href="#angle-brackets">Angle Brackets</a></li> <li><a class="reference internal" href="#bounds-syntax">Bounds Syntax</a></li> <li><a class="reference internal" href="#explicit-variance">Explicit Variance</a></li> <li><a class="reference internal" href="#name-mangling">Name Mangling</a></li> </ul> </li> <li><a class="reference internal" href="#appendix-a-survey-of-type-parameter-syntax">Appendix A: Survey of Type Parameter Syntax</a><ul> <li><a class="reference internal" href="#c">C++</a></li> <li><a class="reference internal" href="#java">Java</a></li> <li><a class="reference internal" href="#id2">C#</a></li> <li><a class="reference internal" href="#typescript">TypeScript</a></li> <li><a class="reference internal" href="#scala">Scala</a></li> <li><a class="reference internal" href="#swift">Swift</a></li> <li><a class="reference internal" href="#rust">Rust</a></li> <li><a class="reference internal" href="#kotlin">Kotlin</a></li> <li><a class="reference internal" href="#julia">Julia</a></li> <li><a class="reference internal" href="#dart">Dart</a></li> <li><a class="reference internal" href="#go">Go</a></li> <li><a class="reference internal" href="#summary">Summary</a></li> </ul> </li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <div class="pep-banner canonical-typing-spec sticky-banner admonition important"> Important This PEP is a historical document: see <a class="reference external" href="https://typing.python.org/en/latest/spec/generics.html#variance-inference" title="(in typing)">Variance Inference</a>, <a class="reference external" href="https://typing.python.org/en/latest/spec/aliases.html#type-aliases" title="(in typing)">Type aliases</a>, <a class="reference external" href="https://docs.python.org/3/reference/compound_stmts.html#type-params" title="(in Python v3.13)">Type parameter lists</a>, <a class="reference external" href="https://docs.python.org/3/reference/simple_stmts.html#type" title="(in Python v3.13)">The type statement</a> and <a class="reference external" href="https://docs.python.org/3/reference/executionmodel.html#annotation-scopes" title="(in Python v3.13)">Annotation scopes</a>. for up-to-date specs and documentation. Canonical typing specs are maintained at the <a class="reference external" href="https://typing.python.org/en/latest/spec/">typing specs site</a>; runtime typing behaviour is described in the CPython documentation. × See the <a class="reference external" href="https://typing.python.org/en/latest/spec/meta.html">typing specification update process</a> for how to propose changes to the typing spec. </div> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> This PEP specifies an improved syntax for specifying type parameters within a generic class, function, or type alias. It also introduces a new statement for declaring type aliases. </section> <section id="motivation"> <h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2> <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a> introduced type variables into the language. <a class="pep reference internal" href="../pep-0612/" title="PEP 612 – Parameter Specification Variables">PEP 612</a> built upon this concept by introducing parameter specifications, and <a class="pep reference internal" href="../pep-0646/" title="PEP 646 – Variadic Generics">PEP 646</a> added variadic type variables. While generic types and type parameters have grown in popularity, the syntax for specifying type parameters still feels “bolted on” to Python. This is a source of confusion among Python developers. There is consensus within the Python static typing community that it is time to provide a formal syntax that is similar to other modern programming languages that support generic types. An analysis of 25 popular typed Python libraries revealed that type variables (in particular, the <code class="docutils literal notranslate">typing.TypeVar</code> symbol) were used in 14% of modules. <section id="points-of-confusion"> <h3><a class="toc-backref" href="#points-of-confusion" role="doc-backlink">Points of Confusion</a></h3> While the use of type variables has become widespread, the manner in which they are specified within code is the source of confusion among many Python developers. There are a couple of factors that contribute to this confusion. The scoping rules for type variables are difficult to understand. Type variables are typically allocated within the global scope, but their semantic meaning is valid only when used within the context of a generic class, function, or type alias. A single runtime instance of a type variable may be reused in multiple generic contexts, and it has a different semantic meaning in each of these contexts. This PEP proposes to eliminate this source of confusion by declaring type parameters at a natural place within a class, function, or type alias declaration statement. Generic type aliases are often misused because it is not clear to developers that a type argument must be supplied when the type alias is used. This leads to an implied type argument of <code class="docutils literal notranslate">Any</code>, which is rarely the intent. This PEP proposes to add new syntax that makes generic type alias declarations clear. <a class="pep reference internal" href="../pep-0483/" title="PEP 483 – The Theory of Type Hints">PEP 483</a> and <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a> introduced the concept of “variance” for a type variable used within a generic class. Type variables can be invariant, covariant, or contravariant. The concept of variance is an advanced detail of type theory that is not well understood by most Python developers, yet they must confront this concept today when defining their first generic class. This PEP largely eliminates the need for most developers to understand the concept of variance when defining generic classes. When more than one type parameter is used with a generic class or type alias, the rules for type parameter ordering can be confusing. It is normally based on the order in which they first appear within a class or type alias declaration statement. However, this can be overridden in a class definition by including a “Generic” or “Protocol” base class. For example, in the class declaration <code class="docutils literal notranslate">class ClassA(Mapping[K, V])</code>, the type parameters are ordered as <code class="docutils literal notranslate">K</code> and then <code class="docutils literal notranslate">V</code>. However, in the class declaration <code class="docutils literal notranslate">class ClassB(Mapping[K, V], Generic[V, K])</code>, the type parameters are ordered as <code class="docutils literal notranslate">V</code> and then <code class="docutils literal notranslate">K</code>. This PEP proposes to make type parameter ordering explicit in all cases. The practice of sharing a type variable across multiple generic contexts creates other problems today. Modern editors provide features like “find all references” and “rename all references” that operate on symbols at the semantic level. When a type parameter is shared among multiple generic classes, functions, and type aliases, all references are semantically equivalent. Type variables defined within the global scope also need to be given a name that starts with an underscore to indicate that the variable is private to the module. Globally-defined type variables are also often given names to indicate their variance, leading to cumbersome names like “_T_contra” and “_KT_co”. The current mechanisms for allocating type variables also requires the developer to supply a redundant name in quotes (e.g. <code class="docutils literal notranslate">T = TypeVar("T")</code>). This PEP eliminates the need for the redundant name and cumbersome variable names. Defining type parameters today requires importing the <code class="docutils literal notranslate">TypeVar</code> and <code class="docutils literal notranslate">Generic</code> symbols from the <code class="docutils literal notranslate">typing</code> module. Over the past several releases of Python, efforts have been made to eliminate the need to import <code class="docutils literal notranslate">typing</code> symbols for common use cases, and the PEP furthers this goal. </section> </section> <section id="summary-examples"> <h2><a class="toc-backref" href="#summary-examples" role="doc-backlink">Summary Examples</a></h2> Defining a generic class prior to this PEP looks something like this. <div class="highlight-default notranslate"><div class="highlight"><pre>from typing import Generic, TypeVar _T_co = TypeVar("_T_co", covariant=True, bound=str) class ClassA(Generic[_T_co]): def method1(self) -> _T_co: ... </pre></div> </div> With the new syntax, it looks like this. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[T: str]: def method1(self) -> T: ... </pre></div> </div> Here is an example of a generic function today. <div class="highlight-default notranslate"><div class="highlight"><pre>from typing import TypeVar _T = TypeVar("_T") def func(a: _T, b: _T) -> _T: ... </pre></div> </div> And the new syntax. <div class="highlight-default notranslate"><div class="highlight"><pre>def func[T](a: T, b: T) -> T: ... </pre></div> </div> Here is an example of a generic type alias today. <div class="highlight-default notranslate"><div class="highlight"><pre>from typing import TypeAlias _T = TypeVar("_T") ListOrSet: TypeAlias = list[_T] | set[_T] </pre></div> </div> And with the new syntax. <div class="highlight-default notranslate"><div class="highlight"><pre>type ListOrSet[T] = list[T] | set[T] </pre></div> </div> </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> <section id="type-parameter-declarations"> <h3><a class="toc-backref" href="#type-parameter-declarations" role="doc-backlink">Type Parameter Declarations</a></h3> Here is a new syntax for declaring type parameters for generic classes, functions, and type aliases. The syntax adds support for a comma-delimited list of type parameters in square brackets after the name of the class, function, or type alias. Simple (non-variadic) type variables are declared with an unadorned name. Variadic type variables are preceded by <code class="docutils literal notranslate">*</code> (see <a class="pep reference internal" href="../pep-0646/" title="PEP 646 – Variadic Generics">PEP 646</a> for details). Parameter specifications are preceded by <code class="docutils literal notranslate">**</code> (see <a class="pep reference internal" href="../pep-0612/" title="PEP 612 – Parameter Specification Variables">PEP 612</a> for details). <div class="highlight-default notranslate"><div class="highlight"><pre># This generic class is parameterized by a TypeVar T, a # TypeVarTuple Ts, and a ParamSpec P. class ChildClass[T, *Ts, **P]: ... </pre></div> </div> There is no need to include <code class="docutils literal notranslate">Generic</code> as a base class. Its inclusion as a base class is implied by the presence of type parameters, and it will automatically be included in the <code class="docutils literal notranslate">__mro__</code> and <code class="docutils literal notranslate">__orig_bases__</code> attributes for the class. The explicit use of a <code class="docutils literal notranslate">Generic</code> base class will result in a runtime error. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[T](Generic[T]): ... # Runtime error </pre></div> </div> A <code class="docutils literal notranslate">Protocol</code> base class with type arguments may generate a runtime error. Type checkers should generate an error in this case because the use of type arguments is not needed, and the order of type parameters for the class are no longer dictated by their order in the <code class="docutils literal notranslate">Protocol</code> base class. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[S, T](Protocol): ... # OK class ClassB[S, T](Protocol[S, T]): ... # Recommended type checker error </pre></div> </div> Type parameter names within a generic class, function, or type alias must be unique within that same class, function, or type alias. A duplicate name generates a syntax error at compile time. This is consistent with the requirement that parameter names within a function signature must be unique. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[T, *T]: ... # Syntax Error def func1[T, **T](): ... # Syntax Error </pre></div> </div> Class type parameter names are mangled if they begin with a double underscore, to avoid complicating the name lookup mechanism for names used within the class. However, the <code class="docutils literal notranslate">__name__</code> attribute of the type parameter will hold the non-mangled name. </section> <section id="upper-bound-specification"> <h3><a class="toc-backref" href="#upper-bound-specification" role="doc-backlink">Upper Bound Specification</a></h3> For a non-variadic type parameter, an “upper bound” type can be specified through the use of a type annotation expression. If an upper bound is not specified, the upper bound is assumed to be <code class="docutils literal notranslate">object</code>. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[T: str]: ... </pre></div> </div> The specified upper bound type must use an expression form that is allowed in type annotations. More complex expression forms should be flagged as an error by a type checker. Quoted forward references are allowed. The specified upper bound type must be concrete. An attempt to use a generic type should be flagged as an error by a type checker. This is consistent with the existing rules enforced by type checkers for a <code class="docutils literal notranslate">TypeVar</code> constructor call. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[T: dict[str, int]]: ... # OK class ClassB[T: "ForwardReference"]: ... # OK class ClassC[V]: class ClassD[T: dict[str, V]]: ... # Type checker error: generic type class ClassE[T: [str, int]]: ... # Type checker error: illegal expression form </pre></div> </div> </section> <section id="constrained-type-specification"> <h3><a class="toc-backref" href="#constrained-type-specification" role="doc-backlink">Constrained Type Specification</a></h3> <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a> introduced the concept of a “constrained type variable” which is constrained to a set of two or more types. The new syntax supports this type of constraint through the use of a literal tuple expression that contains two or more types. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[AnyStr: (str, bytes)]: ... # OK class ClassB[T: ("ForwardReference", bytes)]: ... # OK class ClassC[T: ()]: ... # Type checker error: two or more types required class ClassD[T: (str, )]: ... # Type checker error: two or more types required t1 = (bytes, str) class ClassE[T: t1]: ... # Type checker error: literal tuple expression required </pre></div> </div> If the specified type is not a tuple expression or the tuple expression includes complex expression forms that are not allowed in a type annotation, a type checker should generate an error. Quoted forward references are allowed. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassF[T: (3, bytes)]: ... # Type checker error: invalid expression form </pre></div> </div> The specified constrained types must be concrete. An attempt to use a generic type should be flagged as an error by a type checker. This is consistent with the existing rules enforced by type checkers for a <code class="docutils literal notranslate">TypeVar</code> constructor call. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassG[T: (list[S], str)]: ... # Type checker error: generic type </pre></div> </div> </section> <section id="runtime-representation-of-bounds-and-constraints"> <h3><a class="toc-backref" href="#runtime-representation-of-bounds-and-constraints" role="doc-backlink">Runtime Representation of Bounds and Constraints</a></h3> The upper bounds and constraints of <code class="docutils literal notranslate">TypeVar</code> objects are accessible at runtime through the <code class="docutils literal notranslate">__bound__</code> and <code class="docutils literal notranslate">__constraints__</code> attributes. For <code class="docutils literal notranslate">TypeVar</code> objects defined through the new syntax, these attributes become lazily evaluated, as discussed under <a class="reference internal" href="#lazy-evaluation">Lazy Evaluation</a> below. </section> <section id="generic-type-alias"> <h3><a class="toc-backref" href="#generic-type-alias" role="doc-backlink">Generic Type Alias</a></h3> We propose to introduce a new statement for declaring type aliases. Similar to <code class="docutils literal notranslate">class</code> and <code class="docutils literal notranslate">def</code> statements, a <code class="docutils literal notranslate">type</code> statement defines a scope for type parameters. <div class="highlight-default notranslate"><div class="highlight"><pre># A non-generic type alias type IntOrStr = int | str # A generic type alias type ListOrSet[T] = list[T] | set[T] </pre></div> </div> Type aliases can refer to themselves without the use of quotes. <div class="highlight-default notranslate"><div class="highlight"><pre># A type alias that includes a forward reference type AnimalOrVegetable = Animal | "Vegetable" # A generic self-referential type alias type RecursiveList[T] = T | list[RecursiveList[T]] </pre></div> </div> The <code class="docutils literal notranslate">type</code> keyword is a new soft keyword. It is interpreted as a keyword only in this part of the grammar. In all other locations, it is assumed to be an identifier name. Type parameters declared as part of a generic type alias are valid only when evaluating the right-hand side of the type alias. As with <code class="docutils literal notranslate">typing.TypeAlias</code>, type checkers should restrict the right-hand expression to expression forms that are allowed within type annotations. The use of more complex expression forms (call expressions, ternary operators, arithmetic operators, comparison operators, etc.) should be flagged as an error. Type alias expressions are not allowed to use traditional type variables (i.e. those allocated with an explicit <code class="docutils literal notranslate">TypeVar</code> constructor call). Type checkers should generate an error in this case. <div class="highlight-default notranslate"><div class="highlight"><pre>T = TypeVar("T") type MyList = list[T] # Type checker error: traditional type variable usage </pre></div> </div> We propose to deprecate the existing <code class="docutils literal notranslate">typing.TypeAlias</code> introduced in <a class="pep reference internal" href="../pep-0613/" title="PEP 613 – Explicit Type Aliases">PEP 613</a>. The new syntax eliminates its need entirely. </section> <section id="runtime-type-alias-class"> <h3><a class="toc-backref" href="#runtime-type-alias-class" role="doc-backlink">Runtime Type Alias Class</a></h3> At runtime, a <code class="docutils literal notranslate">type</code> statement will generate an instance of <code class="docutils literal notranslate">typing.TypeAliasType</code>. This class represents the type. Its attributes include: <ul class="simple"> <li><code class="docutils literal notranslate">__name__</code> is a str representing the name of the type alias</li> <li><code class="docutils literal notranslate">__type_params__</code> is a tuple of <code class="docutils literal notranslate">TypeVar</code>, <code class="docutils literal notranslate">TypeVarTuple</code>, or <code class="docutils literal notranslate">ParamSpec</code> objects that parameterize the type alias if it is generic</li> <li><code class="docutils literal notranslate">__value__</code> is the evaluated value of the type alias</li> </ul> All of these attributes are read-only. The value of the type alias is evaluated lazily (see <a class="reference internal" href="#lazy-evaluation">Lazy Evaluation</a> below). </section> <section id="type-parameter-scopes"> <h3><a class="toc-backref" href="#type-parameter-scopes" role="doc-backlink">Type Parameter Scopes</a></h3> When the new syntax is used, a new lexical scope is introduced, and this scope includes the type parameters. Type parameters can be accessed by name within inner scopes. As with other symbols in Python, an inner scope can define its own symbol that overrides an outer-scope symbol of the same name. This section provides a verbal description of the new scoping rules. The <a class="reference internal" href="#id1">Scoping Behavior</a> section below specifies the behavior in terms of a translation to near-equivalent existing Python code. Type parameters are visible to other type parameters declared elsewhere in the list. This allows type parameters to use other type parameters within their definition. While there is currently no use for this capability, it preserves the ability in the future to support upper bound expressions or type argument defaults that depend on earlier type parameters. A compiler error or runtime exception is generated if the definition of an earlier type parameter references a later type parameter even if the name is defined in an outer scope. <div class="highlight-default notranslate"><div class="highlight"><pre># The following generates no compiler error, but a type checker # should generate an error because an upper bound type must be concrete, # and ``Sequence[S]`` is generic. Future extensions to the type system may # eliminate this limitation. class ClassA[S, T: Sequence[S]]: ... # The following generates no compiler error, because the bound for ``S`` # is lazily evaluated. However, type checkers should generate an error. class ClassB[S: Sequence[T], T]: ... </pre></div> </div> A type parameter declared as part of a generic class is valid within the class body and inner scopes contained therein. Type parameters are also accessible when evaluating the argument list (base classes and any keyword arguments) that comprise the class definition. This allows base classes to be parameterized by these type parameters. Type parameters are not accessible outside of the class body, including class decorators. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[T](BaseClass[T], param = Foo[T]): ... # OK print(T) # Runtime error: 'T' is not defined @dec(Foo[T]) # Runtime error: 'T' is not defined class ClassA[T]: ... </pre></div> </div> A type parameter declared as part of a generic function is valid within the function body and any scopes contained therein. It is also valid within parameter and return type annotations. Default argument values for function parameters are evaluated outside of this scope, so type parameters are not accessible in default value expressions. Likewise, type parameters are not in scope for function decorators. <div class="highlight-default notranslate"><div class="highlight"><pre>def func1[T](a: T) -> T: ... # OK print(T) # Runtime error: 'T' is not defined def func2[T](a = list[T]): ... # Runtime error: 'T' is not defined @dec(list[T]) # Runtime error: 'T' is not defined def func3[T](): ... </pre></div> </div> A type parameter declared as part of a generic type alias is valid within the type alias expression. <div class="highlight-default notranslate"><div class="highlight"><pre>type Alias1[K, V] = Mapping[K, V] | Sequence[K] </pre></div> </div> Type parameter symbols defined in outer scopes cannot be bound with <code class="docutils literal notranslate">nonlocal</code> statements in inner scopes. <div class="highlight-default notranslate"><div class="highlight"><pre>S = 0 def outer1[S](): S = 1 T = 1 def outer2[T](): def inner1(): nonlocal S # OK because it binds variable S from outer1 nonlocal T # Syntax error: nonlocal binding not allowed for type parameter def inner2(): global S # OK because it binds variable S from global scope </pre></div> </div> The lexical scope introduced by the new type parameter syntax is unlike traditional scopes introduced by a <code class="docutils literal notranslate">def</code> or <code class="docutils literal notranslate">class</code> statement. A type parameter scope acts more like a temporary “overlay” to the containing scope. The only new symbols contained within its symbol table are the type parameters defined using the new syntax. References to all other symbols are treated as though they were found within the containing scope. This allows base class lists (in class definitions) and type annotation expressions (in function definitions) to reference symbols defined in the containing scope. <div class="highlight-default notranslate"><div class="highlight"><pre>class Outer: class Private: pass # If the type parameter scope was like a traditional scope, # the base class 'Private' would not be accessible here. class Inner[T](Private, Sequence[T]): pass # Likewise, 'Inner' would not be available in these type annotations. def method1[T](self, a: Inner[T]) -> Inner[T]: return a </pre></div> </div> The compiler allows inner scopes to define a local symbol that overrides an outer-scoped type parameter. Consistent with the scoping rules defined in <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a>, type checkers should generate an error if inner-scoped generic classes, functions, or type aliases reuse the same type parameter name as an outer scope. <div class="highlight-default notranslate"><div class="highlight"><pre>T = 0 @decorator(T) # Argument expression `T` evaluates to 0 class ClassA[T](Sequence[T]): T = 1 # All methods below should result in a type checker error # "type parameter 'T' already in use" because they are using the # type parameter 'T', which is already in use by the outer scope # 'ClassA'. def method1[T](self): ... def method2[T](self, x = T): # Parameter 'x' gets default value of 1 ... def method3[T](self, x: T): # Parameter 'x' has type T (scoped to method3) ... </pre></div> </div> Symbols referenced in inner scopes are resolved using existing rules except that type parameter scopes are also considered during name resolution. <div class="highlight-default notranslate"><div class="highlight"><pre>T = 0 # T refers to the global variable print(T) # Prints 0 class Outer[T]: T = 1 # T refers to the local variable scoped to class 'Outer' print(T) # Prints 1 class Inner1: T = 2 # T refers to the local type variable within 'Inner1' print(T) # Prints 2 def inner_method(self): # T refers to the type parameter scoped to class 'Outer'; # If 'Outer' did not use the new type parameter syntax, # this would instead refer to the global variable 'T' print(T) # Prints 'T' def outer_method(self): T = 3 # T refers to the local variable within 'outer_method' print(T) # Prints 3 def inner_func(): # T refers to the variable captured from 'outer_method' print(T) # Prints 3 </pre></div> </div> When the new type parameter syntax is used for a generic class, assignment expressions are not allowed within the argument list for the class definition. Likewise, with functions that use the new type parameter syntax, assignment expressions are not allowed within parameter or return type annotations, nor are they allowed within the expression that defines a type alias, or within the bounds and constraints of a <code class="docutils literal notranslate">TypeVar</code>. Similarly, <code class="docutils literal notranslate">yield</code>, <code class="docutils literal notranslate">yield from</code>, and <code class="docutils literal notranslate">await</code> expressions are disallowed in these contexts. This restriction is necessary because expressions evaluated within the new lexical scope should not introduce symbols within that scope other than the defined type parameters, and should not affect whether the enclosing function is a generator or coroutine. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[T]((x := Sequence[T])): ... # Syntax error: assignment expression not allowed def func1[T](val: (x := int)): ... # Syntax error: assignment expression not allowed def func2[T]() -> (x := Sequence[T]): ... # Syntax error: assignment expression not allowed type Alias1[T] = (x := list[T]) # Syntax error: assignment expression not allowed </pre></div> </div> </section> <section id="accessing-type-parameters-at-runtime"> <h3><a class="toc-backref" href="#accessing-type-parameters-at-runtime" role="doc-backlink">Accessing Type Parameters at Runtime</a></h3> A new attribute called <code class="docutils literal notranslate">__type_params__</code> is available on generic classes, functions, and type aliases. This attribute is a tuple of the type parameters that parameterize the class, function, or alias. The tuple contains <code class="docutils literal notranslate">TypeVar</code>, <code class="docutils literal notranslate">ParamSpec</code>, and <code class="docutils literal notranslate">TypeVarTuple</code> instances. Type parameters declared using the new syntax will not appear within the dictionary returned by <code class="docutils literal notranslate">globals()</code> or <code class="docutils literal notranslate">locals()</code>. </section> <section id="variance-inference"> <h3><a class="toc-backref" href="#variance-inference" role="doc-backlink">Variance Inference</a></h3> This PEP eliminates the need for variance to be specified for type parameters. Instead, type checkers will infer the variance of type parameters based on their usage within a class. Type parameters are inferred to be invariant, covariant, or contravariant depending on how they are used. Python type checkers already include the ability to determine the variance of type parameters for the purpose of validating variance within a generic protocol class. This capability can be used for all classes (whether or not they are protocols) to calculate the variance of each type parameter. The algorithm for computing the variance of a type parameter is as follows. For each type parameter in a generic class: 1. If the type parameter is variadic (<code class="docutils literal notranslate">TypeVarTuple</code>) or a parameter specification (<code class="docutils literal notranslate">ParamSpec</code>), it is always considered invariant. No further inference is needed. 2. If the type parameter comes from a traditional <code class="docutils literal notranslate">TypeVar</code> declaration and is not specified as <code class="docutils literal notranslate">infer_variance</code> (see below), its variance is specified by the <code class="docutils literal notranslate">TypeVar</code> constructor call. No further inference is needed. 3. Create two specialized versions of the class. We’ll refer to these as <code class="docutils literal notranslate">upper</code> and <code class="docutils literal notranslate">lower</code> specializations. In both of these specializations, replace all type parameters other than the one being inferred by a dummy type instance (a concrete anonymous class that is type compatible with itself and assumed to meet the bounds or constraints of the type parameter). In the <code class="docutils literal notranslate">upper</code> specialized class, specialize the target type parameter with an <code class="docutils literal notranslate">object</code> instance. This specialization ignores the type parameter’s upper bound or constraints. In the <code class="docutils literal notranslate">lower</code> specialized class, specialize the target type parameter with itself (i.e. the corresponding type argument is the type parameter itself). 4. Determine whether <code class="docutils literal notranslate">lower</code> can be assigned to <code class="docutils literal notranslate">upper</code> using normal type compatibility rules. If so, the target type parameter is covariant. If not, determine whether <code class="docutils literal notranslate">upper</code> can be assigned to <code class="docutils literal notranslate">lower</code>. If so, the target type parameter is contravariant. If neither of these combinations are assignable, the target type parameter is invariant. Here is an example. <div class="highlight-default notranslate"><div class="highlight"><pre>class ClassA[T1, T2, T3](list[T1]): def method1(self, a: T2) -> None: ... def method2(self) -> T3: ... </pre></div> </div> To determine the variance of <code class="docutils literal notranslate">T1</code>, we specialize <code class="docutils literal notranslate">ClassA</code> as follows: <div class="highlight-default notranslate"><div class="highlight"><pre>upper = ClassA[object, Dummy, Dummy] lower = ClassA[T1, Dummy, Dummy] </pre></div> </div> We find that <code class="docutils literal notranslate">upper</code> is not assignable to <code class="docutils literal notranslate">lower</code> using normal type compatibility rules defined in <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a>. Likewise, <code class="docutils literal notranslate">lower</code> is not assignable to <code class="docutils literal notranslate">upper</code>, so we conclude that <code class="docutils literal notranslate">T1</code> is invariant. To determine the variance of <code class="docutils literal notranslate">T2</code>, we specialize <code class="docutils literal notranslate">ClassA</code> as follows: <div class="highlight-default notranslate"><div class="highlight"><pre>upper = ClassA[Dummy, object, Dummy] lower = ClassA[Dummy, T2, Dummy] </pre></div> </div> Since <code class="docutils literal notranslate">upper</code> is assignable to <code class="docutils literal notranslate">lower</code>, <code class="docutils literal notranslate">T2</code> is contravariant. To determine the variance of <code class="docutils literal notranslate">T3</code>, we specialize <code class="docutils literal notranslate">ClassA</code> as follows: <div class="highlight-default notranslate"><div class="highlight"><pre>upper = ClassA[Dummy, Dummy, object] lower = ClassA[Dummy, Dummy, T3] </pre></div> </div> Since <code class="docutils literal notranslate">lower</code> is assignable to <code class="docutils literal notranslate">upper</code>, <code class="docutils literal notranslate">T3</code> is covariant. </section> <section id="auto-variance-for-typevar"> <h3><a class="toc-backref" href="#auto-variance-for-typevar" role="doc-backlink">Auto Variance For TypeVar</a></h3> The existing <code class="docutils literal notranslate">TypeVar</code> class constructor accepts keyword parameters named <code class="docutils literal notranslate">covariant</code> and <code class="docutils literal notranslate">contravariant</code>. If both of these are <code class="docutils literal notranslate">False</code>, the type variable is assumed to be invariant. We propose to add another keyword parameter named <code class="docutils literal notranslate">infer_variance</code> indicating that a type checker should use inference to determine whether the type variable is invariant, covariant or contravariant. A corresponding instance variable <code class="docutils literal notranslate">__infer_variance__</code> can be accessed at runtime to determine whether the variance is inferred. Type variables that are implicitly allocated using the new syntax will always have <code class="docutils literal notranslate">__infer_variance__</code> set to <code class="docutils literal notranslate">True</code>. A generic class that uses the traditional syntax may include combinations of type variables with explicit and inferred variance. <div class="highlight-default notranslate"><div class="highlight"><pre>T1 = TypeVar("T1", infer_variance=True) # Inferred variance T2 = TypeVar("T2") # Invariant T3 = TypeVar("T3", covariant=True) # Covariant # A type checker should infer the variance for T1 but use the # specified variance for T2 and T3. class ClassA(Generic[T1, T2, T3]): ... </pre></div> </div> </section> <section id="compatibility-with-traditional-typevars"> <h3><a class="toc-backref" href="#compatibility-with-traditional-typevars" role="doc-backlink">Compatibility with Traditional TypeVars</a></h3> The existing mechanism for allocating <code class="docutils literal notranslate">TypeVar</code>, <code class="docutils literal notranslate">TypeVarTuple</code>, and <code class="docutils literal notranslate">ParamSpec</code> is retained for backward compatibility. However, these “traditional” type variables should not be combined with type parameters allocated using the new syntax. Such a combination should be flagged as an error by type checkers. This is necessary because the type parameter order is ambiguous. It is OK to combine traditional type variables with new-style type parameters if the class, function, or type alias does not use the new syntax. The new-style type parameters must come from an outer scope in this case. <div class="highlight-default notranslate"><div class="highlight"><pre>K = TypeVar("K") class ClassA[V](dict[K, V]): ... # Type checker error class ClassB[K, V](dict[K, V]): ... # OK class ClassC[V]: # The use of K and V for "method1" is OK because it uses the # "traditional" generic function mechanism where type parameters # are implicit. In this case V comes from an outer scope (ClassC) # and K is introduced implicitly as a type parameter for "method1". def method1(self, a: V, b: K) -> V | K: ... # The use of M and K are not allowed for "method2". A type checker # should generate an error in this case because this method uses the # new syntax for type parameters, and all type parameters associated # with the method must be explicitly declared. In this case, ``K`` # is not declared by "method2", nor is it supplied by a new-style # type parameter defined in an outer scope. def method2[M](self, a: M, b: K) -> M | K: ... </pre></div> </div> </section> </section> <section id="runtime-implementation"> <h2><a class="toc-backref" href="#runtime-implementation" role="doc-backlink">Runtime Implementation</a></h2> <section id="grammar-changes"> <h3><a class="toc-backref" href="#grammar-changes" role="doc-backlink">Grammar Changes</a></h3> This PEP introduces a new soft keyword <code class="docutils literal notranslate">type</code>. It modifies the grammar in the following ways: <ol class="arabic simple"> <li>Addition of optional type parameter clause in <code class="docutils literal notranslate">class</code> and <code class="docutils literal notranslate">def</code> statements.</li> </ol> <div class="highlight-default notranslate"><div class="highlight"><pre>type_params: '[' t=type_param_seq ']' type_param_seq: a[asdl_typeparam_seq*]=','.type_param+ [','] type_param: | a=NAME b=[type_param_bound] | '*' a=NAME | '**' a=NAME type_param_bound: ":" e=expression # Grammar definitions for class_def_raw and function_def_raw are modified # to reference type_params as an optional syntax element. The definitions # of class_def_raw and function_def_raw are simplified here for brevity. class_def_raw: 'class' n=NAME t=[type_params] ... function_def_raw: a=[ASYNC] 'def' n=NAME t=[type_params] ... </pre></div> </div> <ol class="arabic simple" start="2"> <li>Addition of new <code class="docutils literal notranslate">type</code> statement for defining type aliases.</li> </ol> <div class="highlight-default notranslate"><div class="highlight"><pre>type_alias: "type" n=NAME t=[type_params] '=' b=expression </pre></div> </div> </section> <section id="ast-changes"> <h3><a class="toc-backref" href="#ast-changes" role="doc-backlink">AST Changes</a></h3> This PEP introduces a new AST node type called <code class="docutils literal notranslate">TypeAlias</code>. <div class="highlight-default notranslate"><div class="highlight"><pre>TypeAlias(expr name, typeparam* typeparams, expr value) </pre></div> </div> It also adds an AST node type that represents a type parameter. <div class="highlight-default notranslate"><div class="highlight"><pre>typeparam = TypeVar(identifier name, expr? bound) | ParamSpec(identifier name) | TypeVarTuple(identifier name) </pre></div> </div> Bounds and constraints are represented identically in the AST. In the implementation, any expression that is a <code class="docutils literal notranslate">Tuple</code> AST node is treated as a constraint, and any other expression is treated as a bound. It also modifies existing AST node types <code class="docutils literal notranslate">FunctionDef</code>, <code class="docutils literal notranslate">AsyncFunctionDef</code> and <code class="docutils literal notranslate">ClassDef</code> to include an additional optional attribute called <code class="docutils literal notranslate">typeparams</code> that includes a list of type parameters associated with the function or class. </section> <section id="lazy-evaluation"> <h3><a class="toc-backref" href="#lazy-evaluation" role="doc-backlink">Lazy Evaluation</a></h3> This PEP introduces three new contexts where expressions may occur that represent static types: <code class="docutils literal notranslate">TypeVar</code> bounds, <code class="docutils literal notranslate">TypeVar</code> constraints, and the value of type aliases. These expressions may contain references to names that are not yet defined. For example, type aliases may be recursive, or even mutually recursive, and type variable bounds may refer back to the current class. If these expressions were evaluated eagerly, users would need to enclose such expressions in quotes to prevent runtime errors. <a class="pep reference internal" href="../pep-0563/" title="PEP 563 – Postponed Evaluation of Annotations">PEP 563</a> and <a class="pep reference internal" href="../pep-0649/" title="PEP 649 – Deferred Evaluation Of Annotations Using Descriptors">PEP 649</a> detail the problems with this situation for type annotations. To prevent a similar situation with the new syntax proposed in this PEP, we propose to use lazy evaluation for these expressions, similar to the approach in <a class="pep reference internal" href="../pep-0649/" title="PEP 649 – Deferred Evaluation Of Annotations Using Descriptors">PEP 649</a>. Specifically, each expression will be saved in a code object, and the code object is evaluated only when the corresponding attribute is accessed (<code class="docutils literal notranslate">TypeVar.__bound__</code>, <code class="docutils literal notranslate">TypeVar.__constraints__</code>, or <code class="docutils literal notranslate">TypeAlias.__value__</code>). After the value is successfully evaluated, the value is saved and later calls will return the same value without re-evaluating the code object. If <a class="pep reference internal" href="../pep-0649/" title="PEP 649 – Deferred Evaluation Of Annotations Using Descriptors">PEP 649</a> is implemented, additional evaluation mechanisms should be added to mirror the options that PEP provides for annotations. In the current version of the PEP, that might include adding an <code class="docutils literal notranslate">__evaluate_bound__</code> method to <code class="docutils literal notranslate">TypeVar</code> taking a <code class="docutils literal notranslate">format</code> parameter with the same meaning as in PEP 649’s <code class="docutils literal notranslate">__annotate__</code> method (and a similar <code class="docutils literal notranslate">__evaluate_constraints__</code> method, as well as an <code class="docutils literal notranslate">__evaluate_value__</code> method on <code class="docutils literal notranslate">TypeAliasType</code>). However, until PEP 649 is accepted and implemented, only the default evaluation format (PEP 649’s “VALUE” format) will be supported. As a consequence of lazy evaluation, the value observed for an attribute may depend on the time the attribute is accessed. <div class="highlight-default notranslate"><div class="highlight"><pre>X = int class Foo[T: X, U: X]: t, u = T, U print(Foo.t.__bound__) # prints "int" X = str print(Foo.u.__bound__) # prints "str" </pre></div> </div> Similar examples affecting type annotations can be constructed using the semantics of PEP 563 or PEP 649. A naive implementation of lazy evaluation would handle class namespaces incorrectly, because functions within a class do not normally have access to the enclosing class namespace. The implementation will retain a reference to the class namespace so that class-scoped names are resolved correctly. </section> <section id="scoping-behavior"> <h3><a class="toc-backref" href="#scoping-behavior" role="doc-backlink">Scoping Behavior</a></h3> The new syntax requires a new kind of scope that behaves differently from existing scopes in Python. Thus, the new syntax cannot be described exactly in terms of existing Python scoping behavior. This section specifies these scopes further by reference to existing scoping behavior: the new scopes behave like function scopes, except for a number of minor differences listed below. All examples include functions introduced with the pseudo-keyword <code class="docutils literal notranslate">def695</code>. This keyword will not exist in the actual language; it is used to clarify that the new scopes are for the most part like function scopes. <code class="docutils literal notranslate">def695</code> scopes differ from regular function scopes in the following ways: <ul class="simple"> <li>If a <code class="docutils literal notranslate">def695</code> scope is immediately within a class scope, or within another <code class="docutils literal notranslate">def695</code> scope that is immediately within a class scope, then names defined in that class scope can be accessed within the <code class="docutils literal notranslate">def695</code> scope. (Regular functions, by contrast, cannot access names defined within an enclosing class scope.)</li> <li>The following constructs are disallowed directly within a <code class="docutils literal notranslate">def695</code> scope, though they may be used within other scopes nested inside a <code class="docutils literal notranslate">def695</code> scope:<ul> <li><code class="docutils literal notranslate">yield</code></li> <li><code class="docutils literal notranslate">yield from</code></li> <li><code class="docutils literal notranslate">await</code></li> <li><code class="docutils literal notranslate">:=</code> (walrus operator)</li> </ul> </li> <li>The qualified name (<code class="docutils literal notranslate">__qualname__</code>) of objects (classes and functions) defined within <code class="docutils literal notranslate">def695</code> scopes is as if the objects were defined within the closest enclosing scope.</li> <li>Names bound within <code class="docutils literal notranslate">def695</code> scopes cannot be rebound with a <code class="docutils literal notranslate">nonlocal</code> statement in nested scopes.</li> </ul> <code class="docutils literal notranslate">def695</code> scopes are used for the evaluation of several new syntactic constructs proposed in this PEP. Some are evaluated eagerly (when a type alias, function, or class is defined); others are evaluated lazily (only when evaluation is specifically requested). In all cases, the scoping semantics are identical: <ul class="simple"> <li>Eagerly evaluated values:<ul> <li>The type parameters of generic type aliases</li> <li>The type parameters and annotations of generic functions</li> <li>The type parameters and base class expressions of generic classes</li> </ul> </li> <li>Lazily evaluated values:<ul> <li>The value of generic type aliases</li> <li>The bounds of type variables</li> <li>The constraints of type variables</li> </ul> </li> </ul> In the below translations, names that start with two underscores are internal to the implementation and not visible to actual Python code. We use the following intrinsic functions, which in the real implementation are defined directly in the interpreter: <ul class="simple"> <li><code class="docutils literal notranslate">__make_typealias(*, name, type_params=(), evaluate_value)</code>: Creates a new <code class="docutils literal notranslate">typing.TypeAlias</code> object with the given name, type parameters, and lazily evaluated value. The value is not evaluated until the <code class="docutils literal notranslate">__value__</code> attribute is accessed.</li> <li><code class="docutils literal notranslate">__make_typevar_with_bound(*, name, evaluate_bound)</code>: Creates a new <code class="docutils literal notranslate">typing.TypeVar</code> object with the given name and lazily evaluated bound. The bound is not evaluated until the <code class="docutils literal notranslate">__bound__</code> attribute is accessed.</li> <li><code class="docutils literal notranslate">__make_typevar_with_constraints(*, name, evaluate_constraints)</code>: Creates a new <code class="docutils literal notranslate">typing.TypeVar</code> object with the given name and lazily evaluated constraints. The constraints are not evaluated until the <code class="docutils literal notranslate">__constraints__</code> attribute is accessed.</li> </ul> Non-generic type aliases are translated as follows: <div class="highlight-default notranslate"><div class="highlight"><pre>type Alias = int </pre></div> </div> Equivalent to: <div class="highlight-default notranslate"><div class="highlight"><pre>def695 __evaluate_Alias(): return int Alias = __make_typealias(name='Alias', evaluate_value=__evaluate_Alias) </pre></div> </div> Generic type aliases: <div class="highlight-default notranslate"><div class="highlight"><pre>type Alias[T: int] = list[T] </pre></div> </div> Equivalent to: <div class="highlight-default notranslate"><div class="highlight"><pre>def695 __generic_parameters_of_Alias(): def695 __evaluate_T_bound(): return int T = __make_typevar_with_bound(name='T', evaluate_bound=__evaluate_T_bound) def695 __evaluate_Alias(): return list[T] return __make_typealias(name='Alias', type_params=(T,), evaluate_value=__evaluate_Alias) Alias = __generic_parameters_of_Alias() </pre></div> </div> Generic functions: <div class="highlight-default notranslate"><div class="highlight"><pre>def f[T](x: T) -> T: return x </pre></div> </div> Equivalent to: <div class="highlight-default notranslate"><div class="highlight"><pre>def695 __generic_parameters_of_f(): T = typing.TypeVar(name='T') def f(x: T) -> T: return x f.__type_params__ = (T,) return f f = __generic_parameters_of_f() </pre></div> </div> A fuller example of generic functions, illustrating the scoping behavior of defaults, decorators, and bounds. Note that this example does not use <code class="docutils literal notranslate">ParamSpec</code> correctly, so it should be rejected by a static type checker. It is however valid at runtime, and it us used here to illustrate the runtime semantics. <div class="highlight-default notranslate"><div class="highlight"><pre>@decorator def f[T: int, U: (int, str), *Ts, **P]( x: T = SOME_CONSTANT, y: U, *args: *Ts, **kwargs: P.kwargs, ) -> T: return x </pre></div> </div> Equivalent to: <div class="highlight-default notranslate"><div class="highlight"><pre>__default_of_x = SOME_CONSTANT # evaluated outside the def695 scope def695 __generic_parameters_of_f(): def695 __evaluate_T_bound(): return int T = __make_typevar_with_bound(name='T', evaluate_bound=__evaluate_T_bound) def695 __evaluate_U_constraints(): return (int, str) U = __make_typevar_with_constraints(name='U', evaluate_constraints=__evaluate_U_constraints) Ts = typing.TypeVarTuple("Ts") P = typing.ParamSpec("P") def f(x: T = __default_of_x, y: U, *args: *Ts, **kwargs: P.kwargs) -> T: return x f.__type_params__ = (T, U, Ts, P) return f f = decorator(__generic_parameters_of_f()) </pre></div> </div> Generic classes: <div class="highlight-default notranslate"><div class="highlight"><pre>class C[T](Base): def __init__(self, x: T): self.x = x </pre></div> </div> Equivalent to: <div class="highlight-default notranslate"><div class="highlight"><pre>def695 __generic_parameters_of_C(): T = typing.TypeVar('T') class C(Base): __type_params__ = (T,) def __init__(self, x: T): self.x = x return C C = __generic_parameters_of_C() </pre></div> </div> The biggest divergence from existing behavior for <code class="docutils literal notranslate">def695</code> scopes is the behavior within class scopes. This divergence is necessary so that generics defined within classes behave in an intuitive way: <div class="highlight-default notranslate"><div class="highlight"><pre>class C: class Nested: ... def generic_method[T](self, x: T, y: Nested) -> T: ... </pre></div> </div> Equivalent to: <div class="highlight-default notranslate"><div class="highlight"><pre>class C: class Nested: ... def695 __generic_parameters_of_generic_method(): T = typing.TypeVar('T') def generic_method(self, x: T, y: Nested) -> T: ... return generic_method generic_method = __generic_parameters_of_generic_method() </pre></div> </div> In this example, the annotations for <code class="docutils literal notranslate">x</code> and <code class="docutils literal notranslate">y</code> are evaluated within a <code class="docutils literal notranslate">def695</code> scope, because they need access to the type parameter <code class="docutils literal notranslate">T</code> for the generic method. However, they also need access to the <code class="docutils literal notranslate">Nested</code> name defined within the class namespace. If <code class="docutils literal notranslate">def695</code> scopes behaved like regular function scopes, <code class="docutils literal notranslate">Nested</code> would not be visible within the function scope. Therefore, <code class="docutils literal notranslate">def695</code> scopes that are immediately within class scopes have access to that class scope, as described above. </section> <section id="library-changes"> <h3><a class="toc-backref" href="#library-changes" role="doc-backlink">Library Changes</a></h3> Several classes in the <code class="docutils literal notranslate">typing</code> module that are currently implemented in Python must be partially implemented in C. This includes <code class="docutils literal notranslate">TypeVar</code>, <code class="docutils literal notranslate">TypeVarTuple</code>, <code class="docutils literal notranslate">ParamSpec</code>, and <code class="docutils literal notranslate">Generic</code>, and the new class <code class="docutils literal notranslate">TypeAliasType</code> (described above). The implementation may delegate to the Python version of <code class="docutils literal notranslate">typing.py</code> for some behaviors that interact heavily with the rest of the module. The documented behaviors of these classes should not change. </section> </section> <section id="reference-implementation"> <h2><a class="toc-backref" href="#reference-implementation" role="doc-backlink">Reference Implementation</a></h2> This proposal is prototyped in <a class="reference external" href="https://github.com/python/cpython/pull/103764">CPython PR #103764</a>. The Pyright type checker supports the behavior described in this PEP. </section> <section id="rejected-ideas"> <h2><a class="toc-backref" href="#rejected-ideas" role="doc-backlink">Rejected Ideas</a></h2> <section id="prefix-clause"> <h3><a class="toc-backref" href="#prefix-clause" role="doc-backlink">Prefix Clause</a></h3> We explored various syntactic options for specifying type parameters that preceded <code class="docutils literal notranslate">def</code> and <code class="docutils literal notranslate">class</code> statements. One such variant we considered used a <code class="docutils literal notranslate">using</code> clause as follows: <div class="highlight-default notranslate"><div class="highlight"><pre>using S, T class ClassA: ... </pre></div> </div> This option was rejected because the scoping rules for the type parameters were less clear. Also, this syntax did not interact well with class and function decorators, which are common in Python. Only one other popular programming language, C++, uses this approach. We likewise considered prefix forms that looked like decorators (e.g., <code class="docutils literal notranslate">@using(S, T)</code>). This idea was rejected because such forms would be confused with regular decorators, and they would not compose well with existing decorators. Furthermore, decorators are logically executed after the statement they are decorating, so it would be confusing for them to introduce symbols (type parameters) that are visible within the “decorated” statement, which is logically executed before the decorator itself. </section> <section id="angle-brackets"> <h3><a class="toc-backref" href="#angle-brackets" role="doc-backlink">Angle Brackets</a></h3> Many languages that support generics make use of angle brackets. (Refer to the table at the end of Appendix A for a summary.) We explored the use of angle brackets for type parameter declarations in Python, but we ultimately rejected it for two reasons. First, angle brackets are not considered “paired” by the Python scanner, so end-of-line characters between a <code class="docutils literal notranslate"><</code> and <code class="docutils literal notranslate">></code> token are retained. That means any line breaks within a list of type parameters would require the use of unsightly and cumbersome <code class="docutils literal notranslate">\</code> escape sequences. Second, Python has already established the use of square brackets for explicit specialization of a generic type (e.g., <code class="docutils literal notranslate">list[int]</code>). We concluded that it would be inconsistent and confusing to use angle brackets for generic declarations but square brackets for explicit specialization. All other languages that we surveyed were consistent in this regard. </section> <section id="bounds-syntax"> <h3><a class="toc-backref" href="#bounds-syntax" role="doc-backlink">Bounds Syntax</a></h3> We explored various syntactic options for specifying the bounds and constraints for a type variable. We considered, but ultimately rejected, the use of a <code class="docutils literal notranslate"><:</code> token like in Scala, the use of an <code class="docutils literal notranslate">extends</code> or <code class="docutils literal notranslate">with</code> keyword like in various other languages, and the use of a function call syntax similar to today’s <code class="docutils literal notranslate">typing.TypeVar</code> constructor. The simple colon syntax is consistent with many other programming languages (see Appendix A), and it was heavily preferred by a cross section of Python developers who were surveyed. </section> <section id="explicit-variance"> <h3><a class="toc-backref" href="#explicit-variance" role="doc-backlink">Explicit Variance</a></h3> We considered adding syntax for specifying whether a type parameter is intended to be invariant, covariant, or contravariant. The <code class="docutils literal notranslate">typing.TypeVar</code> mechanism in Python requires this. A few other languages including Scala and C# also require developers to specify the variance. We rejected this idea because variance can generally be inferred, and most modern programming languages do infer variance based on usage. Variance is an advanced topic that many developers find confusing, so we want to eliminate the need to understand this concept for most Python developers. </section> <section id="name-mangling"> <h3><a class="toc-backref" href="#name-mangling" role="doc-backlink">Name Mangling</a></h3> When considering implementation options, we considered a “name mangling” approach where each type parameter was given a unique “mangled” name by the compiler. This mangled name would be based on the qualified name of the generic class, function or type alias it was associated with. This approach was rejected because qualified names are not necessarily unique, which means the mangled name would need to be based on some other randomized value. Furthermore, this approach is not compatible with techniques used for evaluating quoted (forward referenced) type annotations. </section> </section> <section id="appendix-a-survey-of-type-parameter-syntax"> <h2><a class="toc-backref" href="#appendix-a-survey-of-type-parameter-syntax" role="doc-backlink">Appendix A: Survey of Type Parameter Syntax</a></h2> Support for generic types is found in many programming languages. In this section, we provide a survey of the options used by other popular programming languages. This is relevant because familiarity with other languages will make it easier for Python developers to understand this concept. We provide additional details here (for example, default type argument support) that may be useful when considering future extensions to the Python type system. <section id="c"> <h3><a class="toc-backref" href="#c" role="doc-backlink">C++</a></h3> C++ uses angle brackets in combination with keywords <code class="docutils literal notranslate">template</code> and <code class="docutils literal notranslate">typename</code> to declare type parameters. It uses angle brackets for specialization. C++20 introduced the notion of generalized constraints, which can act like protocols in Python. A collection of constraints can be defined in a named entity called a <code class="docutils literal notranslate">concept</code>. Variance is not explicitly specified, but constraints can enforce variance. A default type argument can be specified using the <code class="docutils literal notranslate">=</code> operator. <div class="highlight-c++ notranslate"><div class="highlight"><pre>// Generic class template <typename> class ClassA { // Constraints are supported through compile-time assertions. static_assert(std::is_base_of<BaseClass, T>::value); public: Container<T> t; }; // Generic function with default type argument template <typename S = int> S func1(ClassA<S> a, S b) {}; // C++20 introduced a more generalized notion of "constraints" // and "concepts", which are named constraints. // A sample concept template<typename T> concept Hashable = requires(T a) { { std::hash<T>{}(a) } -> std::convertible_to<std::size_t>; }; // Use of a concept in a template template<Hashable T> void func2(T value) {} // Alternative use of concept template<typename T> requires Hashable<T> void func3(T value) {} // Alternative use of concept template<typename T> void func3(T value) requires Hashable<T> {} </pre></div> </div> </section> <section id="java"> <h3><a class="toc-backref" href="#java" role="doc-backlink">Java</a></h3> Java uses angle brackets to declare type parameters and for specialization. By default, type parameters are invariant. The <code class="docutils literal notranslate">extends</code> keyword is used to specify an upper bound. The <code class="docutils literal notranslate">super</code> keyword is used to specify a contravariant bound. Java uses use-site variance. The compiler places limits on which methods and members can be accessed based on the use of a generic type. Variance is not specified explicitly. Java provides no way to specify a default type argument. <div class="highlight-java notranslate"><div class="highlight"><pre>// Generic class public class ClassA<T> { public Container<T> t; // Generic method public <S extends Number> void method1(S value) { } // Use site variance public void method1(ClassA<? super Integer> value) { } } </pre></div> </div> </section> <section id="id2"> <h3><a class="toc-backref" href="#id2" role="doc-backlink">C#</a></h3> C# uses angle brackets to declare type parameters and for specialization. The <code class="docutils literal notranslate">where</code> keyword and a colon is used to specify the bound for a type parameter. C# uses declaration-site variance using the keywords <code class="docutils literal notranslate">in</code> and <code class="docutils literal notranslate">out</code> for contravariance and covariance, respectively. By default, type parameters are invariant. C# provides no way to specify a default type argument. <div class="highlight-c# notranslate"><div class="highlight"><pre>// Generic class with bounds on type parameters public class ClassA<S, T> where T : SomeClass1 where S : SomeClass2 { // Generic method public void MyMethod<U>(U value) where U : SomeClass3 { } } // Contravariant and covariant type parameters public class ClassB<in S, out T> { public T MyMethod(S value) { } } </pre></div> </div> </section> <section id="typescript"> <h3><a class="toc-backref" href="#typescript" role="doc-backlink">TypeScript</a></h3> TypeScript uses angle brackets to declare type parameters and for specialization. The <code class="docutils literal notranslate">extends</code> keyword is used to specify a bound. It can be combined with other type operators such as <code class="docutils literal notranslate">keyof</code>. TypeScript uses declaration-site variance. Variance is inferred from usage, not specified explicitly. TypeScript 4.7 introduced the ability to specify variance using <code class="docutils literal notranslate">in</code> and <code class="docutils literal notranslate">out</code> keywords. This was added to handle extremely complex types where inference of variance was expensive. A default type argument can be specified using the <code class="docutils literal notranslate">=</code> operator. TypeScript supports the <code class="docutils literal notranslate">type</code> keyword to declare a type alias, and this syntax supports generics. <div class="highlight-typescript notranslate"><div class="highlight"><pre>// Generic interface interface InterfaceA<S, T extends SomeInterface1> { val1: S; val2: T; method1<U extends SomeInterface2>(val: U): S } // Generic function function func1<T, K extends keyof T>(ojb: T, key: K) { } // Contravariant and covariant type parameters (TypeScript 4.7) interface InterfaceB<in S, out T> { } // Type parameter with default interface InterfaceC<T = SomeInterface3> { } // Generic type alias type MyType<T extends SomeInterface4> = Array<T> </pre></div> </div> </section> <section id="scala"> <h3><a class="toc-backref" href="#scala" role="doc-backlink">Scala</a></h3> In Scala, square brackets are used to declare type parameters. Square brackets are also used for specialization. The <code class="docutils literal notranslate"><:</code> and <code class="docutils literal notranslate">>:</code> operators are used to specify upper and lower bounds, respectively. Scala uses use-site variance but also allows declaration-site variance specification. It uses a <code class="docutils literal notranslate">+</code> or <code class="docutils literal notranslate">-</code> prefix operator for covariance and contravariance, respectively. Scala provides no way to specify a default type argument. It does support higher-kinded types (type parameters that accept type type parameters). <div class="highlight-scala notranslate"><div class="highlight"><pre>// Generic class; type parameter has upper bound class ClassA[A <: SomeClass1] { // Generic method; type parameter has lower bound def method1[B >: A](val: B) ... } // Use of an upper and lower bound with the same type parameter class ClassB[A >: SomeClass1 <: SomeClass2] { } // Contravariant and covariant type parameters class ClassC[+A, -B] { } // Higher-kinded type trait Collection[T[_]] { def method1[A](a: A): T[A] def method2[B](b: T[B]): B } // Generic type alias type MyType[T <: Int] = Container[T] </pre></div> </div> </section> <section id="swift"> <h3><a class="toc-backref" href="#swift" role="doc-backlink">Swift</a></h3> Swift uses angle brackets to declare type parameters and for specialization. The upper bound of a type parameter is specified using a colon. Swift doesn’t support generic variance; all type parameters are invariant. Swift provides no way to specify a default type argument. <div class="highlight-swift notranslate"><div class="highlight"><pre>// Generic class class ClassA<T> { // Generic method func method1<X>(val: T) -> X { } } // Type parameter with upper bound constraint class ClassB<T: SomeClass1> {} // Generic type alias typealias MyType<A> = Container<A> </pre></div> </div> </section> <section id="rust"> <h3><a class="toc-backref" href="#rust" role="doc-backlink">Rust</a></h3> Rust uses angle brackets to declare type parameters and for specialization. The upper bound of a type parameter is specified using a colon. Alternatively a <code class="docutils literal notranslate">where</code> clause can specify various constraints. Rust does not have traditional object oriented inheritance or variance. Subtyping in Rust is very restricted and occurs only due to variance with respect to lifetimes. A default type argument can be specified using the <code class="docutils literal notranslate">=</code> operator. <div class="highlight-rust notranslate"><div class="highlight"><pre>// Generic class struct StructA<T> { // T's lifetime is inferred as covariant x: T } fn f<'a>( mut short_lifetime: StructA<&'a i32>, mut long_lifetime: StructA<&'static i32>, ) { long_lifetime = short_lifetime; // error: StructA<&'a i32> is not a subtype of StructA<&'static i32> short_lifetime = long_lifetime; // valid: StructA<&'static i32> is a subtype of StructA<&'a i32> } // Type parameter with bound struct StructB<T: SomeTrait> {} // Type parameter with additional constraints struct StructC<T> where T: Iterator, T::Item: Copy {} // Generic function fn func1<T>(val: &[T]) -> T { } // Generic type alias type MyType<T> = StructC<T>; </pre></div> </div> </section> <section id="kotlin"> <h3><a class="toc-backref" href="#kotlin" role="doc-backlink">Kotlin</a></h3> Kotlin uses angle brackets to declare type parameters and for specialization. By default, type parameters are invariant. The upper bound of a type is specified using a colon. Alternatively, a <code class="docutils literal notranslate">where</code> clause can specify various constraints. Kotlin supports declaration-site variance where variance of type parameters is explicitly declared using <code class="docutils literal notranslate">in</code> and <code class="docutils literal notranslate">out</code> keywords. It also supports use-site variance which limits which methods and members can be used. Kotlin provides no way to specify a default type argument. <div class="highlight-kotlin notranslate"><div class="highlight"><pre>// Generic class class ClassA<T> // Type parameter with upper bound class ClassB<T : SomeClass1> // Contravariant and covariant type parameters class ClassC<in S, out T> // Generic function fun <T> func1(): T { // Use site variance val covariantA: ClassA<out Number> val contravariantA: ClassA<in Number> } // Generic type alias typealias TypeAliasFoo<T> = ClassA<T> </pre></div> </div> </section> <section id="julia"> <h3><a class="toc-backref" href="#julia" role="doc-backlink">Julia</a></h3> Julia uses curly braces to declare type parameters and for specialization. The <code class="docutils literal notranslate"><:</code> operator can be used within a <code class="docutils literal notranslate">where</code> clause to declare upper and lower bounds on a type. <div class="highlight-julia notranslate"><div class="highlight"><pre># Generic struct; type parameter with upper and lower bounds # Valid for T in (Int64, Signed, Integer, Real, Number) struct Container{Int <: T <: Number} x::T end # Generic function function func1(v::Container{T}) where T <: Real end # Alternate forms of generic function function func2(v::Container{T} where T <: Real) end function func3(v::Container{<: Real}) end # Tuple types are covariant # Valid for func4((2//3, 3.5)) function func4(t::Tuple{Real,Real}) end </pre></div> </div> </section> <section id="dart"> <h3><a class="toc-backref" href="#dart" role="doc-backlink">Dart</a></h3> Dart uses angle brackets to declare type parameters and for specialization. The upper bound of a type is specified using the <code class="docutils literal notranslate">extends</code> keyword. By default, type parameters are covariant. Dart supports declaration-site variance, where variance of type parameters is explicitly declared using <code class="docutils literal notranslate">in</code>, <code class="docutils literal notranslate">out</code> and <code class="docutils literal notranslate">inout</code> keywords. It does not support use-site variance. Dart provides no way to specify a default type argument. <div class="highlight-dart notranslate"><div class="highlight"><pre>// Generic class class ClassA<T> { } // Type parameter with upper bound class ClassB<T extends SomeClass1> { } // Contravariant and covariant type parameters class ClassC<in S, out T> { } // Generic function T func1<T>() { } // Generic type alias typedef TypeDefFoo<T> = ClassA<T>; </pre></div> </div> </section> <section id="go"> <h3><a class="toc-backref" href="#go" role="doc-backlink">Go</a></h3> Go uses square brackets to declare type parameters and for specialization. The upper bound of a type is specified after the name of the parameter, and must always be specified. The keyword <code class="docutils literal notranslate">any</code> is used for an unbound type parameter. Go doesn’t support variance; all type parameters are invariant. Go provides no way to specify a default type argument. Go does not support generic type aliases. <div class="highlight-go notranslate"><div class="highlight"><pre>// Generic type without a bound type TypeA[T any] struct { t T } // Type parameter with upper bound type TypeB[T SomeType1] struct { } // Generic function func func1[T any]() { } </pre></div> </div> </section> <section id="summary"> <h3><a class="toc-backref" href="#summary" role="doc-backlink">Summary</a></h3> <table class="docutils align-default"> <thead> <tr class="row-odd"><th class="head"></th> <th class="head">Decl Syntax</th> <th class="head">Upper Bound</th> <th class="head">Lower Bound</th> <th class="head">Default Value</th> <th class="head">Variance Site</th> <th class="head">Variance</th> </tr> </thead> <tbody> <tr class="row-even"><td>C++</td> <td>template <></td> <td>n/a</td> <td>n/a</td> <td>=</td> <td>n/a</td> <td>n/a</td> </tr> <tr class="row-odd"><td>Java</td> <td><></td> <td>extends</td> <td></td> <td></td> <td>use</td> <td>super, extends</td> </tr> <tr class="row-even"><td>C#</td> <td><></td> <td>where</td> <td></td> <td></td> <td>decl</td> <td>in, out</td> </tr> <tr class="row-odd"><td>TypeScript</td> <td><></td> <td>extends</td> <td></td> <td>=</td> <td>decl</td> <td>inferred, in, out</td> </tr> <tr class="row-even"><td>Scala</td> <td>[]</td> <td>T <: X</td> <td>T >: X</td> <td></td> <td>use, decl</td> <td>+, -</td> </tr> <tr class="row-odd"><td>Swift</td> <td><></td> <td>T: X</td> <td></td> <td></td> <td>n/a</td> <td>n/a</td> </tr> <tr class="row-even"><td>Rust</td> <td><></td> <td>T: X, where</td> <td></td> <td>=</td> <td>n/a</td> <td>n/a</td> </tr> <tr class="row-odd"><td>Kotlin</td> <td><></td> <td>T: X, where</td> <td></td> <td></td> <td>use, decl</td> <td>in, out</td> </tr> <tr class="row-even"><td>Julia</td> <td>{}</td> <td>T <: X</td> <td>X <: T</td> <td></td> <td>n/a</td> <td>n/a</td> </tr> <tr class="row-odd"><td>Dart</td> <td><></td> <td>extends</td> <td></td> <td></td> <td>decl</td> <td>in, out, inout</td> </tr> <tr class="row-even"><td>Go</td> <td>[]</td> <td>T X</td> <td></td> <td></td> <td>n/a</td> <td>n/a</td> </tr> <tr class="row-odd"><td>Python (proposed)</td> <td>[]</td> <td>T: X</td> <td></td> <td></td> <td>decl</td> <td>inferred</td> </tr> </tbody> </table> </section> </section> <section id="acknowledgements"> <h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2> Thanks to Sebastian Rittau for kick-starting the discussions that led to this proposal, to Jukka Lehtosalo for proposing the syntax for type alias statements and to Jelle Zijlstra, Daniel Moisset, and Guido van Rossum for their valuable feedback and suggested improvements to the specification and implementation. </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-0695.rst">https://github.com/python/peps/blob/main/peps/pep-0695.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0695.rst">2025-02-01 07:28:42 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="#points-of-confusion">Points of Confusion</a></li> </ul> </li> <li><a class="reference internal" href="#summary-examples">Summary Examples</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#type-parameter-declarations">Type Parameter Declarations</a></li> <li><a class="reference internal" href="#upper-bound-specification">Upper Bound Specification</a></li> <li><a class="reference internal" href="#constrained-type-specification">Constrained Type Specification</a></li> <li><a class="reference internal" href="#runtime-representation-of-bounds-and-constraints">Runtime Representation of Bounds and Constraints</a></li> <li><a class="reference internal" href="#generic-type-alias">Generic Type Alias</a></li> <li><a class="reference internal" href="#runtime-type-alias-class">Runtime Type Alias Class</a></li> <li><a class="reference internal" href="#type-parameter-scopes">Type Parameter Scopes</a></li> <li><a class="reference internal" href="#accessing-type-parameters-at-runtime">Accessing Type Parameters at Runtime</a></li> <li><a class="reference internal" href="#variance-inference">Variance Inference</a></li> <li><a class="reference internal" href="#auto-variance-for-typevar">Auto Variance For TypeVar</a></li> <li><a class="reference internal" href="#compatibility-with-traditional-typevars">Compatibility with Traditional TypeVars</a></li> </ul> </li> <li><a class="reference internal" href="#runtime-implementation">Runtime Implementation</a><ul> <li><a class="reference internal" href="#grammar-changes">Grammar Changes</a></li> <li><a class="reference internal" href="#ast-changes">AST Changes</a></li> <li><a class="reference internal" href="#lazy-evaluation">Lazy Evaluation</a></li> <li><a class="reference internal" href="#scoping-behavior">Scoping Behavior</a></li> <li><a class="reference internal" href="#library-changes">Library Changes</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="#prefix-clause">Prefix Clause</a></li> <li><a class="reference internal" href="#angle-brackets">Angle Brackets</a></li> <li><a class="reference internal" href="#bounds-syntax">Bounds Syntax</a></li> <li><a class="reference internal" href="#explicit-variance">Explicit Variance</a></li> <li><a class="reference internal" href="#name-mangling">Name Mangling</a></li> </ul> </li> <li><a class="reference internal" href="#appendix-a-survey-of-type-parameter-syntax">Appendix A: Survey of Type Parameter Syntax</a><ul> <li><a class="reference internal" href="#c">C++</a></li> <li><a class="reference internal" href="#java">Java</a></li> <li><a class="reference internal" href="#id2">C#</a></li> <li><a class="reference internal" href="#typescript">TypeScript</a></li> <li><a class="reference internal" href="#scala">Scala</a></li> <li><a class="reference internal" href="#swift">Swift</a></li> <li><a class="reference internal" href="#rust">Rust</a></li> <li><a class="reference internal" href="#kotlin">Kotlin</a></li> <li><a class="reference internal" href="#julia">Julia</a></li> <li><a class="reference internal" href="#dart">Dart</a></li> <li><a class="reference internal" href="#go">Go</a></li> <li><a class="reference internal" href="#summary">Summary</a></li> </ul> </li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</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-0695.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>