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 483 – The Theory of Type Hints | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0483/"> <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 483 – The Theory of Type Hints | peps.python.org'> <meta property="og:description" content="This PEP lays out the theory referenced by PEP 484."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0483/"> <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 lays out the theory referenced by PEP 484."> <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 483</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 483 – The Theory of Type Hints</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Guido van Rossum <guido at python.org>, Ivan Levkivskyi <levkivskyi at gmail.com></dd> <dt class="field-even">Discussions-To:</dt> <dd class="field-even"><a class="reference external" href="https://mail.python.org/archives/list/python-ideas@python.org/">Python-Ideas list</a></dd> <dt class="field-odd">Status:</dt> <dd class="field-odd"><abbr title="Accepted and implementation complete, or no longer active">Final</abbr></dd> <dt class="field-even">Type:</dt> <dd class="field-even"><abbr title="Non-normative PEP containing background, guidelines or other information relevant to the Python ecosystem">Informational</abbr></dd> <dt class="field-odd">Topic:</dt> <dd class="field-odd"><a class="reference external" href="../topic/typing/">Typing</a></dd> <dt class="field-even">Created:</dt> <dd class="field-even">19-Dec-2014</dd> <dt class="field-odd">Post-History:</dt> <dd class="field-odd"></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="#introduction">Introduction</a><ul> <li><a class="reference internal" href="#notational-conventions">Notational conventions</a></li> </ul> </li> <li><a class="reference internal" href="#background">Background</a><ul> <li><a class="reference internal" href="#subtype-relationships">Subtype relationships</a></li> </ul> </li> <li><a class="reference internal" href="#summary-of-gradual-typing">Summary of gradual typing</a><ul> <li><a class="reference internal" href="#types-vs-classes">Types vs. Classes</a></li> <li><a class="reference internal" href="#fundamental-building-blocks">Fundamental building blocks</a></li> </ul> </li> <li><a class="reference internal" href="#generic-types">Generic types</a><ul> <li><a class="reference internal" href="#type-variables">Type variables</a></li> <li><a class="reference internal" href="#defining-and-using-generic-types">Defining and using generic types</a></li> <li><a class="reference internal" href="#covariance-and-contravariance">Covariance and Contravariance</a></li> </ul> </li> <li><a class="reference internal" href="#pragmatics">Pragmatics</a><ul> <li><a class="reference internal" href="#predefined-generic-types-and-protocols-in-typing-py">Predefined generic types and Protocols in typing.py</a></li> </ul> </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> This PEP lays out the theory referenced by <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a>. </section> <section id="introduction"> <h2><a class="toc-backref" href="#introduction" role="doc-backlink">Introduction</a></h2> This document lays out the theory of the new type hinting proposal for Python 3.5. It’s not quite a full proposal or specification because there are many details that need to be worked out, but it lays out the theory without which it is hard to discuss more detailed specifications. We start by recalling basic concepts of type theory; then we explain gradual typing; then we state some general rules and define the new special types (such as <code class="docutils literal notranslate">Union</code>) that can be used in annotations; and finally we define the approach to generic types and pragmatic aspects of type hinting. <section id="notational-conventions"> <h3><a class="toc-backref" href="#notational-conventions" role="doc-backlink">Notational conventions</a></h3> <ul class="simple"> <li><code class="docutils literal notranslate">t1</code>, <code class="docutils literal notranslate">t2</code>, etc. and <code class="docutils literal notranslate">u1</code>, <code class="docutils literal notranslate">u2</code>, etc. are types. Sometimes we write <code class="docutils literal notranslate">ti</code> or <code class="docutils literal notranslate">tj</code> to refer to “any of <code class="docutils literal notranslate">t1</code>, <code class="docutils literal notranslate">t2</code>, etc.”</li> <li><code class="docutils literal notranslate">T</code>, <code class="docutils literal notranslate">U</code> etc. are type variables (defined with <code class="docutils literal notranslate">TypeVar()</code>, see below).</li> <li>Objects, classes defined with a class statement, and instances are denoted using standard <a class="pep reference internal" href="../pep-0008/" title="PEP 8 – Style Guide for Python Code">PEP 8</a> conventions.</li> <li>the symbol <code class="docutils literal notranslate">==</code> applied to types in the context of this PEP means that two expressions represent the same type.</li> <li>Note that <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a> makes a distinction between types and classes (a type is a concept for the type checker, while a class is a runtime concept). In this PEP we clarify this distinction but avoid unnecessary strictness to allow more flexibility in the implementation of type checkers.</li> </ul> </section> </section> <section id="background"> <h2><a class="toc-backref" href="#background" role="doc-backlink">Background</a></h2> There are many definitions of the concept of type in the literature. Here we assume that type is a set of values and a set of functions that one can apply to these values. There are several ways to define a particular type: <ul> <li>By explicitly listing all values. E.g., <code class="docutils literal notranslate">True</code> and <code class="docutils literal notranslate">False</code> form the type <code class="docutils literal notranslate">bool</code>.</li> <li>By specifying functions which can be used with variables of a type. E.g. all objects that have a <code class="docutils literal notranslate">__len__</code> method form the type <code class="docutils literal notranslate">Sized</code>. Both <code class="docutils literal notranslate">[1, 2, 3]</code> and <code class="docutils literal notranslate">'abc'</code> belong to this type, since one can call <code class="docutils literal notranslate">len</code> on them:<div class="highlight-default notranslate"><div class="highlight"><pre>len([1, 2, 3]) # OK len('abc') # also OK len(42) # not a member of Sized </pre></div> </div> </li> <li>By a simple class definition, for example if one defines a class:<div class="highlight-default notranslate"><div class="highlight"><pre>class UserID(int): pass </pre></div> </div> then all instances of this class also form a type. </li> <li>There are also more complex types. E.g., one can define the type <code class="docutils literal notranslate">FancyList</code> as all lists containing only instances of <code class="docutils literal notranslate">int</code>, <code class="docutils literal notranslate">str</code> or their subclasses. The value <code class="docutils literal notranslate">[1, 'abc', UserID(42)]</code> has this type.</li> </ul> It is important for the user to be able to define types in a form that can be understood by type checkers. The goal of this PEP is to propose such a systematic way of defining types for type annotations of variables and functions using <a class="pep reference internal" href="../pep-3107/" title="PEP 3107 – Function Annotations">PEP 3107</a> syntax. These annotations can be used to avoid many kind of bugs, for documentation purposes, or maybe even to increase speed of program execution. Here we only focus on avoiding bugs by using a static type checker. <section id="subtype-relationships"> <h3><a class="toc-backref" href="#subtype-relationships" role="doc-backlink">Subtype relationships</a></h3> A crucial notion for static type checker is the subtype relationship. It arises from the question: If <code class="docutils literal notranslate">first_var</code> has type <code class="docutils literal notranslate">first_type</code>, and <code class="docutils literal notranslate">second_var</code> has type <code class="docutils literal notranslate">second_type</code>, is it safe to assign <code class="docutils literal notranslate">first_var = second_var</code>? A strong criterion for when it should be safe is: <ul class="simple"> <li>every value from <code class="docutils literal notranslate">second_type</code> is also in the set of values of <code class="docutils literal notranslate">first_type</code>; and</li> <li>every function from <code class="docutils literal notranslate">first_type</code> is also in the set of functions of <code class="docutils literal notranslate">second_type</code>.</li> </ul> The relation defined thus is called a subtype relation. By this definition: <ul class="simple"> <li>Every type is a subtype of itself.</li> <li>The set of values becomes smaller in the process of subtyping, while the set of functions becomes larger.</li> </ul> An intuitive example: Every <code class="docutils literal notranslate">Dog</code> is an <code class="docutils literal notranslate">Animal</code>, also <code class="docutils literal notranslate">Dog</code> has more functions, for example it can bark, therefore <code class="docutils literal notranslate">Dog</code> is a subtype of <code class="docutils literal notranslate">Animal</code>. Conversely, <code class="docutils literal notranslate">Animal</code> is not a subtype of <code class="docutils literal notranslate">Dog</code>. A more formal example: Integers are subtype of real numbers. Indeed, every integer is of course also a real number, and integers support more operations, such as, e.g., bitwise shifts <code class="docutils literal notranslate"><<</code> and <code class="docutils literal notranslate">>></code>: <div class="highlight-default notranslate"><div class="highlight"><pre>lucky_number = 3.14 # type: float lucky_number = 42 # Safe lucky_number * 2 # This works lucky_number << 5 # Fails unlucky_number = 13 # type: int unlucky_number << 5 # This works unlucky_number = 2.72 # Unsafe </pre></div> </div> Let us also consider a tricky example: If <code class="docutils literal notranslate">List[int]</code> denotes the type formed by all lists containing only integer numbers, then it is not a subtype of <code class="docutils literal notranslate">List[float]</code>, formed by all lists that contain only real numbers. The first condition of subtyping holds, but appending a real number only works with <code class="docutils literal notranslate">List[float]</code> so that the second condition fails: <div class="highlight-default notranslate"><div class="highlight"><pre>def append_pi(lst: List[float]) -> None: lst += [3.14] my_list = [1, 3, 5] # type: List[int] append_pi(my_list) # Naively, this should be safe... my_list[-1] << 5 # ... but this fails </pre></div> </div> There are two widespread approaches to declare subtype information to type checker. In nominal subtyping, the type tree is based on the class tree, i.e., <code class="docutils literal notranslate">UserID</code> is considered a subtype of <code class="docutils literal notranslate">int</code>. This approach should be used under control of the type checker, because in Python one can override attributes in an incompatible way: <div class="highlight-default notranslate"><div class="highlight"><pre>class Base: answer = '42' # type: str class Derived(Base): answer = 5 # should be marked as error by type checker </pre></div> </div> In structural subtyping the subtype relation is deduced from the declared methods, i.e., <code class="docutils literal notranslate">UserID</code> and <code class="docutils literal notranslate">int</code> would be considered the same type. While this may occasionally cause confusion, structural subtyping is considered more flexible. We strive to provide support for both approaches, so that structural information can be used in addition to nominal subtyping. </section> </section> <section id="summary-of-gradual-typing"> <h2><a class="toc-backref" href="#summary-of-gradual-typing" role="doc-backlink">Summary of gradual typing</a></h2> Gradual typing allows one to annotate only part of a program, thus leverage desirable aspects of both dynamic and static typing. We define a new relationship, is-consistent-with, which is similar to is-subtype-of, except it is not transitive when the new type <code class="docutils literal notranslate">Any</code> is involved. (Neither relationship is symmetric.) Assigning <code class="docutils literal notranslate">a_value</code> to <code class="docutils literal notranslate">a_variable</code> is OK if the type of <code class="docutils literal notranslate">a_value</code> is consistent with the type of <code class="docutils literal notranslate">a_variable</code>. (Compare this to “… if the type of <code class="docutils literal notranslate">a_value</code> is a subtype of the type of <code class="docutils literal notranslate">a_variable</code>”, which states one of the fundamentals of OO programming.) The is-consistent-with relationship is defined by three rules: <ul class="simple"> <li>A type <code class="docutils literal notranslate">t1</code> is consistent with a type <code class="docutils literal notranslate">t2</code> if <code class="docutils literal notranslate">t1</code> is a subtype of <code class="docutils literal notranslate">t2</code>. (But not the other way around.)</li> <li><code class="docutils literal notranslate">Any</code> is consistent with every type. (But <code class="docutils literal notranslate">Any</code> is not a subtype of every type.)</li> <li>Every type is consistent with <code class="docutils literal notranslate">Any</code>. (But every type is not a subtype of <code class="docutils literal notranslate">Any</code>.)</li> </ul> That’s all! See Jeremy Siek’s blog post <a class="reference external" href="http://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/">What is Gradual Typing</a> for a longer explanation and motivation. <code class="docutils literal notranslate">Any</code> can be considered a type that has all values and all methods. Combined with the definition of subtyping above, this places <code class="docutils literal notranslate">Any</code> partially at the top (it has all values) and bottom (it has all methods) of the type hierarchy. Contrast this to <code class="docutils literal notranslate">object</code> – it is not consistent with most types (e.g. you can’t use an <code class="docutils literal notranslate">object()</code> instance where an <code class="docutils literal notranslate">int</code> is expected). IOW both <code class="docutils literal notranslate">Any</code> and <code class="docutils literal notranslate">object</code> mean “any type is allowed” when used to annotate an argument, but only <code class="docutils literal notranslate">Any</code> can be passed no matter what type is expected (in essence, <code class="docutils literal notranslate">Any</code> declares a fallback to dynamic typing and shuts up complaints from the static checker). Here’s an example showing how these rules work out in practice: Say we have an <code class="docutils literal notranslate">Employee</code> class, and a subclass <code class="docutils literal notranslate">Manager</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>class Employee: ... class Manager(Employee): ... </pre></div> </div> Let’s say variable <code class="docutils literal notranslate">worker</code> is declared with type <code class="docutils literal notranslate">Employee</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>worker = Employee() # type: Employee </pre></div> </div> Now it’s okay to assign a <code class="docutils literal notranslate">Manager</code> instance to <code class="docutils literal notranslate">worker</code> (rule 1): <div class="highlight-default notranslate"><div class="highlight"><pre>worker = Manager() </pre></div> </div> It’s not okay to assign an <code class="docutils literal notranslate">Employee</code> instance to a variable declared with type <code class="docutils literal notranslate">Manager</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>boss = Manager() # type: Manager boss = Employee() # Fails static check </pre></div> </div> However, suppose we have a variable whose type is <code class="docutils literal notranslate">Any</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>something = some_func() # type: Any </pre></div> </div> Now it’s okay to assign <code class="docutils literal notranslate">something</code> to <code class="docutils literal notranslate">worker</code> (rule 2): <div class="highlight-default notranslate"><div class="highlight"><pre>worker = something # OK </pre></div> </div> Of course it’s also okay to assign <code class="docutils literal notranslate">worker</code> to <code class="docutils literal notranslate">something</code> (rule 3), but we didn’t need the concept of consistency for that: <div class="highlight-default notranslate"><div class="highlight"><pre>something = worker # OK </pre></div> </div> <section id="types-vs-classes"> <h3><a class="toc-backref" href="#types-vs-classes" role="doc-backlink">Types vs. Classes</a></h3> In Python, classes are object factories defined by the <code class="docutils literal notranslate">class</code> statement, and returned by the <code class="docutils literal notranslate">type(obj)</code> built-in function. Class is a dynamic, runtime concept. Type concept is described above, types appear in variable and function type annotations, can be constructed from building blocks described below, and are used by static type checkers. Every class is a type as discussed above. But it is tricky and error prone to implement a class that exactly represents semantics of a given type, and it is not a goal of <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a>. The static types described in <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a> should not be confused with the runtime classes. Examples: <ul> <li><code class="docutils literal notranslate">int</code> is a class and a type.</li> <li><code class="docutils literal notranslate">UserID</code> is a class and a type.</li> <li><code class="docutils literal notranslate">Union[str, int]</code> is a type but not a proper class:<div class="highlight-default notranslate"><div class="highlight"><pre>class MyUnion(Union[str, int]): ... # raises TypeError Union[str, int]() # raises TypeError </pre></div> </div> </li> </ul> Typing interface is implemented with classes, i.e., at runtime it is possible to evaluate, e.g., <code class="docutils literal notranslate">Generic[T].__bases__</code>. But to emphasize the distinction between classes and types the following general rules apply: <ul class="simple"> <li>No types defined below (i.e. <code class="docutils literal notranslate">Any</code>, <code class="docutils literal notranslate">Union</code>, etc.) can be instantiated, an attempt to do so will raise <code class="docutils literal notranslate">TypeError</code>. (But non-abstract subclasses of <code class="docutils literal notranslate">Generic</code> can be.)</li> <li>No types defined below can be subclassed, except for <code class="docutils literal notranslate">Generic</code> and classes derived from it.</li> <li>All of these will raise <code class="docutils literal notranslate">TypeError</code> if they appear in <code class="docutils literal notranslate">isinstance</code> or <code class="docutils literal notranslate">issubclass</code> (except for unparameterized generics).</li> </ul> </section> <section id="fundamental-building-blocks"> <h3><a class="toc-backref" href="#fundamental-building-blocks" role="doc-backlink">Fundamental building blocks</a></h3> <ul class="simple"> <li>Any. Every type is consistent with <code class="docutils literal notranslate">Any</code>; and it is also consistent with every type (see above).</li> <li>Union[t1, t2, …]. Types that are subtype of at least one of <code class="docutils literal notranslate">t1</code> etc. are subtypes of this.<ul> <li>Unions whose components are all subtypes of <code class="docutils literal notranslate">t1</code> etc. are subtypes of this. Example: <code class="docutils literal notranslate">Union[int, str]</code> is a subtype of <code class="docutils literal notranslate">Union[int, float, str]</code>.</li> <li>The order of the arguments doesn’t matter. Example: <code class="docutils literal notranslate">Union[int, str] == Union[str, int]</code>.</li> <li>If <code class="docutils literal notranslate">ti</code> is itself a <code class="docutils literal notranslate">Union</code> the result is flattened. Example: <code class="docutils literal notranslate">Union[int, Union[float, str]] == Union[int, float, str]</code>.</li> <li>If <code class="docutils literal notranslate">ti</code> and <code class="docutils literal notranslate">tj</code> have a subtype relationship, the less specific type survives. Example: <code class="docutils literal notranslate">Union[Employee, Manager] == Union[Employee]</code>.</li> <li><code class="docutils literal notranslate">Union[t1]</code> returns just <code class="docutils literal notranslate">t1</code>. <code class="docutils literal notranslate">Union[]</code> is illegal, so is <code class="docutils literal notranslate">Union[()]</code></li> <li>Corollary: <code class="docutils literal notranslate">Union[..., object, ...]</code> returns <code class="docutils literal notranslate">object</code>.</li> </ul> </li> <li>Optional[t1]. Alias for <code class="docutils literal notranslate">Union[t1, None]</code>, i.e. <code class="docutils literal notranslate">Union[t1, type(None)]</code>.</li> <li>Tuple[t1, t2, …, tn]. A tuple whose items are instances of <code class="docutils literal notranslate">t1</code>, etc. Example: <code class="docutils literal notranslate">Tuple[int, float]</code> means a tuple of two items, the first is an <code class="docutils literal notranslate">int</code>, the second is a <code class="docutils literal notranslate">float</code>; e.g., <code class="docutils literal notranslate">(42, 3.14)</code>.<ul> <li><code class="docutils literal notranslate">Tuple[u1, u2, ..., um]</code> is a subtype of <code class="docutils literal notranslate">Tuple[t1, t2, ..., tn]</code> if they have the same length <code class="docutils literal notranslate">n==m</code> and each <code class="docutils literal notranslate">ui</code> is a subtype of <code class="docutils literal notranslate">ti</code>.</li> <li>To spell the type of the empty tuple, use <code class="docutils literal notranslate">Tuple[()]</code>.</li> <li>A variadic homogeneous tuple type can be written <code class="docutils literal notranslate">Tuple[t1, ...]</code>. (That’s three dots, a literal ellipsis; and yes, that’s a valid token in Python’s syntax.)</li> </ul> </li> <li>Callable[[t1, t2, …, tn], tr]. A function with positional argument types <code class="docutils literal notranslate">t1</code> etc., and return type <code class="docutils literal notranslate">tr</code>. The argument list may be empty <code class="docutils literal notranslate">n==0</code>. There is no way to indicate optional or keyword arguments, nor varargs, but you can say the argument list is entirely unchecked by writing <code class="docutils literal notranslate">Callable[..., tr]</code> (again, a literal ellipsis).</li> </ul> We might add: <ul class="simple"> <li>Intersection[t1, t2, …]. Types that are subtype of each of <code class="docutils literal notranslate">t1</code>, etc are subtypes of this. (Compare to <code class="docutils literal notranslate">Union</code>, which has at least one instead of each in its definition.)<ul> <li>The order of the arguments doesn’t matter. Nested intersections are flattened, e.g. <code class="docutils literal notranslate">Intersection[int, Intersection[float, str]] == Intersection[int, float, str]</code>.</li> <li>An intersection of fewer types is a supertype of an intersection of more types, e.g. <code class="docutils literal notranslate">Intersection[int, str]</code> is a supertype of <code class="docutils literal notranslate">Intersection[int, float, str]</code>.</li> <li>An intersection of one argument is just that argument, e.g. <code class="docutils literal notranslate">Intersection[int]</code> is <code class="docutils literal notranslate">int</code>.</li> <li>When argument have a subtype relationship, the more specific type survives, e.g. <code class="docutils literal notranslate">Intersection[str, Employee, Manager]</code> is <code class="docutils literal notranslate">Intersection[str, Manager]</code>.</li> <li><code class="docutils literal notranslate">Intersection[]</code> is illegal, so is <code class="docutils literal notranslate">Intersection[()]</code>.</li> <li>Corollary: <code class="docutils literal notranslate">Any</code> disappears from the argument list, e.g. <code class="docutils literal notranslate">Intersection[int, str, Any] == Intersection[int, str]</code>. <code class="docutils literal notranslate">Intersection[Any, object]</code> is <code class="docutils literal notranslate">object</code>.</li> <li>The interaction between <code class="docutils literal notranslate">Intersection</code> and <code class="docutils literal notranslate">Union</code> is complex but should be no surprise if you understand the interaction between intersections and unions of regular sets (note that sets of types can be infinite in size, since there is no limit on the number of new subclasses).</li> </ul> </li> </ul> </section> </section> <section id="generic-types"> <h2><a class="toc-backref" href="#generic-types" role="doc-backlink">Generic types</a></h2> The fundamental building blocks defined above allow to construct new types in a generic manner. For example, <code class="docutils literal notranslate">Tuple</code> can take a concrete type <code class="docutils literal notranslate">float</code> and make a concrete type <code class="docutils literal notranslate">Vector = Tuple[float, ...]</code>, or it can take another type <code class="docutils literal notranslate">UserID</code> and make another concrete type <code class="docutils literal notranslate">Registry = Tuple[UserID, ...]</code>. Such semantics is known as generic type constructor, it is similar to semantics of functions, but a function takes a value and returns a value, while generic type constructor takes a type and “returns” a type. It is common when a particular class or a function behaves in such a type generic manner. Consider two examples: <ul> <li>Container classes, such as <code class="docutils literal notranslate">list</code> or <code class="docutils literal notranslate">dict</code>, typically contain only values of a particular type. Therefore, a user might want to type annotate them as such:<div class="highlight-default notranslate"><div class="highlight"><pre>users = [] # type: List[UserID] users.append(UserID(42)) # OK users.append('Some guy') # Should be rejected by the type checker examples = {} # type: Dict[str, Any] examples['first example'] = object() # OK examples[2] = None # rejected by the type checker </pre></div> </div> </li> <li>The following function can take two arguments of type <code class="docutils literal notranslate">int</code> and return an <code class="docutils literal notranslate">int</code>, or take two arguments of type <code class="docutils literal notranslate">float</code> and return a <code class="docutils literal notranslate">float</code>, etc.:<div class="highlight-default notranslate"><div class="highlight"><pre>def add(x, y): return x + y add(1, 2) == 3 add('1', '2') == '12' add(2.7, 3.5) == 6.2 </pre></div> </div> </li> </ul> To allow type annotations in situations from the first example, built-in containers and container abstract base classes are extended with type parameters, so that they behave as generic type constructors. Classes, that behave as generic type constructors are called generic types. Example: <div class="highlight-default notranslate"><div class="highlight"><pre>from typing import Iterable class Task: ... def work(todo_list: Iterable[Task]) -> None: ... </pre></div> </div> Here <code class="docutils literal notranslate">Iterable</code> is a generic type that takes a concrete type <code class="docutils literal notranslate">Task</code> and returns a concrete type <code class="docutils literal notranslate">Iterable[Task]</code>. Functions that behave in the type generic manner (as in second example) are called generic functions. Type annotations of generic functions are allowed by type variables. Their semantics with respect to generic types is somewhat similar to semantics of parameters in functions. But one does not assign concrete types to type variables, it is the task of a static type checker to find their possible values and warn the user if it cannot find. Example: <div class="highlight-default notranslate"><div class="highlight"><pre>def take_first(seq: Sequence[T]) -> T: # a generic function return seq[0] accumulator = 0 # type: int accumulator += take_first([1, 2, 3]) # Safe, T deduced to be int accumulator += take_first((2.7, 3.5)) # Unsafe </pre></div> </div> Type variables are used extensively in type annotations, also internal machinery of the type inference in type checkers is typically build on type variables. Therefore, let us consider them in detail. <section id="type-variables"> <h3><a class="toc-backref" href="#type-variables" role="doc-backlink">Type variables</a></h3> <code class="docutils literal notranslate">X = TypeVar('X')</code> declares a unique type variable. The name must match the variable name. By default, a type variable ranges over all possible types. Example: <div class="highlight-default notranslate"><div class="highlight"><pre>def do_nothing(one_arg: T, other_arg: T) -> None: pass do_nothing(1, 2) # OK, T is int do_nothing('abc', UserID(42)) # also OK, T is object </pre></div> </div> <code class="docutils literal notranslate">Y = TypeVar('Y', t1, t2, ...)</code>. Ditto, constrained to <code class="docutils literal notranslate">t1</code>, etc. Behaves similar to <code class="docutils literal notranslate">Union[t1, t2, ...]</code>. A constrained type variable ranges only over constrains <code class="docutils literal notranslate">t1</code>, etc. exactly; subclasses of the constrains are replaced by the most-derived base class among <code class="docutils literal notranslate">t1</code>, etc. Examples: <ul> <li>Function type annotation with a constrained type variable:<div class="highlight-default notranslate"><div class="highlight"><pre>AnyStr = TypeVar('AnyStr', str, bytes) def longest(first: AnyStr, second: AnyStr) -> AnyStr: return first if len(first) >= len(second) else second result = longest('a', 'abc') # The inferred type for result is str result = longest('a', b'abc') # Fails static type check </pre></div> </div> In this example, both arguments to <code class="docutils literal notranslate">longest()</code> must have the same type (<code class="docutils literal notranslate">str</code> or <code class="docutils literal notranslate">bytes</code>), and moreover, even if the arguments are instances of a common <code class="docutils literal notranslate">str</code> subclass, the return type is still <code class="docutils literal notranslate">str</code>, not that subclass (see next example). </li> <li>For comparison, if the type variable was unconstrained, the common subclass would be chosen as the return type, e.g.:<div class="highlight-default notranslate"><div class="highlight"><pre>S = TypeVar('S') def longest(first: S, second: S) -> S: return first if len(first) >= len(second) else second class MyStr(str): ... result = longest(MyStr('a'), MyStr('abc')) </pre></div> </div> The inferred type of <code class="docutils literal notranslate">result</code> is <code class="docutils literal notranslate">MyStr</code> (whereas in the <code class="docutils literal notranslate">AnyStr</code> example it would be <code class="docutils literal notranslate">str</code>). </li> <li>Also for comparison, if a <code class="docutils literal notranslate">Union</code> is used, the return type also has to be a <code class="docutils literal notranslate">Union</code>:<div class="highlight-default notranslate"><div class="highlight"><pre>U = Union[str, bytes] def longest(first: U, second: U) -> U: return first if len(first) >= len(second) else second result = longest('a', 'abc') </pre></div> </div> The inferred type of <code class="docutils literal notranslate">result</code> is still <code class="docutils literal notranslate">Union[str, bytes]</code>, even though both arguments are <code class="docutils literal notranslate">str</code>. Note that the type checker will reject this function: <div class="highlight-default notranslate"><div class="highlight"><pre>def concat(first: U, second: U) -> U: return first + second # Error: can't concatenate str and bytes </pre></div> </div> For such cases where parameters could change their types only simultaneously one should use constrained type variables. </li> </ul> </section> <section id="defining-and-using-generic-types"> <h3><a class="toc-backref" href="#defining-and-using-generic-types" role="doc-backlink">Defining and using generic types</a></h3> Users can declare their classes as generic types using the special building block <code class="docutils literal notranslate">Generic</code>. The definition <code class="docutils literal notranslate">class MyGeneric(Generic[X, Y, ...]): ...</code> defines a generic type <code class="docutils literal notranslate">MyGeneric</code> over type variables <code class="docutils literal notranslate">X</code>, etc. <code class="docutils literal notranslate">MyGeneric</code> itself becomes parameterizable, e.g. <code class="docutils literal notranslate">MyGeneric[int, str, ...]</code> is a specific type with substitutions <code class="docutils literal notranslate">X -> int</code>, etc. Example: <div class="highlight-default notranslate"><div class="highlight"><pre>class CustomQueue(Generic[T]): def put(self, task: T) -> None: ... def get(self) -> T: ... def communicate(queue: CustomQueue[str]) -> Optional[str]: ... </pre></div> </div> Classes that derive from generic types become generic. A class can subclass multiple generic types. However, classes derived from specific types returned by generics are not generic. Examples: <div class="highlight-default notranslate"><div class="highlight"><pre>class TodoList(Iterable[T], Container[T]): def check(self, item: T) -> None: ... def check_all(todo: TodoList[T]) -> None: # TodoList is generic ... class URLList(Iterable[bytes]): def scrape_all(self) -> None: ... def search(urls: URLList) -> Optional[bytes] # URLList is not generic ... </pre></div> </div> Subclassing a generic type imposes the subtype relation on the corresponding specific types, so that <code class="docutils literal notranslate">TodoList[t1]</code> is a subtype of <code class="docutils literal notranslate">Iterable[t1]</code> in the above example. Generic types can be specialized (indexed) in several steps. Every type variable could be substituted by a specific type or by another generic type. If <code class="docutils literal notranslate">Generic</code> appears in the base class list, then it should contain all type variables, and the order of type parameters is determined by the order in which they appear in <code class="docutils literal notranslate">Generic</code>. Examples: <div class="highlight-default notranslate"><div class="highlight"><pre>Table = Dict[int, T] # Table is generic Messages = Table[bytes] # Same as Dict[int, bytes] class BaseGeneric(Generic[T, S]): ... class DerivedGeneric(BaseGeneric[int, T]): # DerivedGeneric has one parameter ... SpecificType = DerivedGeneric[int] # OK class MyDictView(Generic[S, T, U], Iterable[Tuple[U, T]]): ... Example = MyDictView[list, int, str] # S -> list, T -> int, U -> str </pre></div> </div> If a generic type appears in a type annotation with a type variable omitted, it is assumed to be <code class="docutils literal notranslate">Any</code>. Such form could be used as a fallback to dynamic typing and is allowed for use with <code class="docutils literal notranslate">issubclass</code> and <code class="docutils literal notranslate">isinstance</code>. All type information in instances is erased at runtime. Examples: <div class="highlight-default notranslate"><div class="highlight"><pre>def count(seq: Sequence) -> int: # Same as Sequence[Any] ... class FrameworkBase(Generic[S, T]): ... class UserClass: ... issubclass(UserClass, FrameworkBase) # This is OK class Node(Generic[T]): ... IntNode = Node[int] my_node = IntNode() # at runtime my_node.__class__ is Node # inferred static type of my_node is Node[int] </pre></div> </div> </section> <section id="covariance-and-contravariance"> <h3><a class="toc-backref" href="#covariance-and-contravariance" role="doc-backlink">Covariance and Contravariance</a></h3> If <code class="docutils literal notranslate">t2</code> is a subtype of <code class="docutils literal notranslate">t1</code>, then a generic type constructor <code class="docutils literal notranslate">GenType</code> is called: <ul class="simple"> <li>Covariant, if <code class="docutils literal notranslate">GenType[t2]</code> is a subtype of <code class="docutils literal notranslate">GenType[t1]</code> for all such <code class="docutils literal notranslate">t1</code> and <code class="docutils literal notranslate">t2</code>.</li> <li>Contravariant, if <code class="docutils literal notranslate">GenType[t1]</code> is a subtype of <code class="docutils literal notranslate">GenType[t2]</code> for all such <code class="docutils literal notranslate">t1</code> and <code class="docutils literal notranslate">t2</code>.</li> <li>Invariant, if neither of the above is true.</li> </ul> To better understand this definition, let us make an analogy with ordinary functions. Assume that we have: <div class="highlight-default notranslate"><div class="highlight"><pre>def cov(x: float) -> float: return 2*x def contra(x: float) -> float: return -x def inv(x: float) -> float: return x*x </pre></div> </div> If <code class="docutils literal notranslate">x1 < x2</code>, then always <code class="docutils literal notranslate">cov(x1) < cov(x2)</code>, and <code class="docutils literal notranslate">contra(x2) < contra(x1)</code>, while nothing could be said about <code class="docutils literal notranslate">inv</code>. Replacing <code class="docutils literal notranslate"><</code> with is-subtype-of, and functions with generic type constructor we get examples of covariant, contravariant, and invariant behavior. Let us now consider practical examples: <ul class="simple"> <li><code class="docutils literal notranslate">Union</code> behaves covariantly in all its arguments. Indeed, as discussed above, <code class="docutils literal notranslate">Union[t1, t2, ...]</code> is a subtype of <code class="docutils literal notranslate">Union[u1, u2, ...]</code>, if <code class="docutils literal notranslate">t1</code> is a subtype of <code class="docutils literal notranslate">u1</code>, etc.</li> <li><code class="docutils literal notranslate">FrozenSet[T]</code> is also covariant. Let us consider <code class="docutils literal notranslate">int</code> and <code class="docutils literal notranslate">float</code> in place of <code class="docutils literal notranslate">T</code>. First, <code class="docutils literal notranslate">int</code> is a subtype of <code class="docutils literal notranslate">float</code>. Second, set of values of <code class="docutils literal notranslate">FrozenSet[int]</code> is clearly a subset of values of <code class="docutils literal notranslate">FrozenSet[float]</code>, while set of functions from <code class="docutils literal notranslate">FrozenSet[float]</code> is a subset of set of functions from <code class="docutils literal notranslate">FrozenSet[int]</code>. Therefore, by definition <code class="docutils literal notranslate">FrozenSet[int]</code> is a subtype of <code class="docutils literal notranslate">FrozenSet[float]</code>.</li> <li><code class="docutils literal notranslate">List[T]</code> is invariant. Indeed, although set of values of <code class="docutils literal notranslate">List[int]</code> is a subset of values of <code class="docutils literal notranslate">List[float]</code>, only <code class="docutils literal notranslate">int</code> could be appended to a <code class="docutils literal notranslate">List[int]</code>, as discussed in section “Background”. Therefore, <code class="docutils literal notranslate">List[int]</code> is not a subtype of <code class="docutils literal notranslate">List[float]</code>. This is a typical situation with mutable types, they are typically invariant.</li> </ul> One of the best examples to illustrate (somewhat counterintuitive) contravariant behavior is the callable type. It is covariant in the return type, but contravariant in the arguments. For two callable types that differ only in the return type, the subtype relationship for the callable types follows that of the return types. Examples: <ul class="simple"> <li><code class="docutils literal notranslate">Callable[[], int]</code> is a subtype of <code class="docutils literal notranslate">Callable[[], float]</code>.</li> <li><code class="docutils literal notranslate">Callable[[], Manager]</code> is a subtype of <code class="docutils literal notranslate">Callable[[], Employee]</code>.</li> </ul> While for two callable types that differ only in the type of one argument, the subtype relationship for the callable types goes in the opposite direction as for the argument types. Examples: <ul class="simple"> <li><code class="docutils literal notranslate">Callable[[float], None]</code> is a subtype of <code class="docutils literal notranslate">Callable[[int], None]</code>.</li> <li><code class="docutils literal notranslate">Callable[[Employee], None]</code> is a subtype of <code class="docutils literal notranslate">Callable[[Manager], None]</code>.</li> </ul> Yes, you read that right. Indeed, if a function that can calculate the salary for a manager is expected: <div class="highlight-default notranslate"><div class="highlight"><pre>def calculate_all(lst: List[Manager], salary: Callable[[Manager], Decimal]): ... </pre></div> </div> then <code class="docutils literal notranslate">Callable[[Employee], Decimal]</code> that can calculate a salary for any employee is also acceptable. The example with <code class="docutils literal notranslate">Callable</code> shows how to make more precise type annotations for functions: choose the most general type for every argument, and the most specific type for the return value. It is possible to declare the variance for user defined generic types by using special keywords <code class="docutils literal notranslate">covariant</code> and <code class="docutils literal notranslate">contravariant</code> in the definition of type variables used as parameters. Types are invariant by default. Examples: <div class="highlight-default notranslate"><div class="highlight"><pre>T = TypeVar('T') T_co = TypeVar('T_co', covariant=True) T_contra = TypeVar('T_contra', contravariant=True) class LinkedList(Generic[T]): # invariant by default ... def append(self, element: T) -> None: ... class Box(Generic[T_co]): # this type is declared covariant def __init__(self, content: T_co) -> None: self._content = content def get_content(self) -> T_co: return self._content class Sink(Generic[T_contra]): # this type is declared contravariant def send_to_nowhere(self, data: T_contra) -> None: with open(os.devnull, 'w') as devnull: print(data, file=devnull) </pre></div> </div> Note, that although the variance is defined via type variables, it is not a property of type variables, but a property of generic types. In complex definitions of derived generics, variance only determined from type variables used. A complex example: <div class="highlight-default notranslate"><div class="highlight"><pre>T_co = TypeVar('T_co', Employee, Manager, covariant=True) T_contra = TypeVar('T_contra', Employee, Manager, contravariant=True) class Base(Generic[T_contra]): ... class Derived(Base[T_co]): ... </pre></div> </div> A type checker finds from the second declaration that <code class="docutils literal notranslate">Derived[Manager]</code> is a subtype of <code class="docutils literal notranslate">Derived[Employee]</code>, and <code class="docutils literal notranslate">Derived[t1]</code> is a subtype of <code class="docutils literal notranslate">Base[t1]</code>. If we denote the is-subtype-of relationship with <code class="docutils literal notranslate"><</code>, then the full diagram of subtyping for this case will be: <div class="highlight-default notranslate"><div class="highlight"><pre>Base[Manager] > Base[Employee] v v Derived[Manager] < Derived[Employee] </pre></div> </div> so that a type checker will also find that, e.g., <code class="docutils literal notranslate">Derived[Manager]</code> is a subtype of <code class="docutils literal notranslate">Base[Employee]</code>. For more information on type variables, generic types, and variance, see <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a>, the <a class="reference external" href="http://mypy.readthedocs.io/en/latest/generics.html">mypy docs on generics</a>, and <a class="reference external" href="http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29">Wikipedia</a>. </section> </section> <section id="pragmatics"> <h2><a class="toc-backref" href="#pragmatics" role="doc-backlink">Pragmatics</a></h2> Some things are irrelevant to the theory but make practical use more convenient. (This is not a full list; I probably missed a few and some are still controversial or not fully specified.) <ul> <li>Where a type is expected, <code class="docutils literal notranslate">None</code> can be substituted for <code class="docutils literal notranslate">type(None)</code>; e.g. <code class="docutils literal notranslate">Union[t1, None] == Union[t1, type(None)]</code>.</li> <li>Type aliases, e.g.:<div class="highlight-default notranslate"><div class="highlight"><pre>Point = Tuple[float, float] def distance(point: Point) -> float: ... </pre></div> </div> </li> <li>Forward references via strings, e.g.:<div class="highlight-default notranslate"><div class="highlight"><pre>class MyComparable: def compare(self, other: 'MyComparable') -> int: ... </pre></div> </div> </li> <li>Type variables can be declared in unconstrained, constrained, or bounded form. The variance of a generic type can also be indicated using a type variable declared with special keyword arguments, thus avoiding any special syntax, e.g.:<div class="highlight-default notranslate"><div class="highlight"><pre>T = TypeVar('T', bound=complex) def add(x: T, y: T) -> T: return x + y T_co = TypeVar('T_co', covariant=True) class ImmutableList(Generic[T_co]): ... </pre></div> </div> </li> <li>Type declaration in comments, e.g.:<div class="highlight-default notranslate"><div class="highlight"><pre>lst = [] # type: Sequence[int] </pre></div> </div> </li> <li>Casts using <code class="docutils literal notranslate">cast(T, obj)</code>, e.g.:<div class="highlight-default notranslate"><div class="highlight"><pre>zork = cast(Any, frobozz()) </pre></div> </div> </li> <li>Other things, e.g. overloading and stub modules, see <a class="pep reference internal" href="../pep-0484/" title="PEP 484 – Type Hints">PEP 484</a>.</li> </ul> <section id="predefined-generic-types-and-protocols-in-typing-py"> <h3><a class="toc-backref" href="#predefined-generic-types-and-protocols-in-typing-py" role="doc-backlink">Predefined generic types and Protocols in typing.py</a></h3> (See also the <a class="reference external" href="https://github.com/python/typing/blob/master/src/typing.py">typing.py module</a>.) <ul class="simple"> <li>Everything from <code class="docutils literal notranslate">collections.abc</code> (but <code class="docutils literal notranslate">Set</code> renamed to <code class="docutils literal notranslate">AbstractSet</code>).</li> <li><code class="docutils literal notranslate">Dict</code>, <code class="docutils literal notranslate">List</code>, <code class="docutils literal notranslate">Set</code>, <code class="docutils literal notranslate">FrozenSet</code>, a few more.</li> <li><code class="docutils literal notranslate">re.Pattern[AnyStr]</code>, <code class="docutils literal notranslate">re.Match[AnyStr]</code>.</li> <li><code class="docutils literal notranslate">io.IO[AnyStr]</code>, <code class="docutils literal notranslate">io.TextIO ~ io.IO[str]</code>, <code class="docutils literal notranslate">io.BinaryIO ~ io.IO[bytes]</code>.</li> </ul> </section> </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> This document is licensed under the <a class="reference external" href="http://www.opencontent.org/openpub/">Open Publication License</a>. </section> </section> <hr class="docutils" /> Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0483.rst">https://github.com/python/peps/blob/main/peps/pep-0483.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0483.rst">2025-02-01 08:59:27 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="#introduction">Introduction</a><ul> <li><a class="reference internal" href="#notational-conventions">Notational conventions</a></li> </ul> </li> <li><a class="reference internal" href="#background">Background</a><ul> <li><a class="reference internal" href="#subtype-relationships">Subtype relationships</a></li> </ul> </li> <li><a class="reference internal" href="#summary-of-gradual-typing">Summary of gradual typing</a><ul> <li><a class="reference internal" href="#types-vs-classes">Types vs. Classes</a></li> <li><a class="reference internal" href="#fundamental-building-blocks">Fundamental building blocks</a></li> </ul> </li> <li><a class="reference internal" href="#generic-types">Generic types</a><ul> <li><a class="reference internal" href="#type-variables">Type variables</a></li> <li><a class="reference internal" href="#defining-and-using-generic-types">Defining and using generic types</a></li> <li><a class="reference internal" href="#covariance-and-contravariance">Covariance and Contravariance</a></li> </ul> </li> <li><a class="reference internal" href="#pragmatics">Pragmatics</a><ul> <li><a class="reference internal" href="#predefined-generic-types-and-protocols-in-typing-py">Predefined generic types and Protocols in typing.py</a></li> </ul> </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-0483.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>