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 443 – Single-dispatch generic functions | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0443/"> <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 443 – Single-dispatch generic functions | peps.python.org'> <meta property="og:description" content="This PEP proposes a new mechanism in the functools standard library module that provides a simple form of generic programming known as single-dispatch generic functions."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0443/"> <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 proposes a new mechanism in the functools standard library module that provides a simple form of generic programming known as single-dispatch generic functions."> <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 443</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 443 – Single-dispatch generic functions</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Łukasz Langa <lukasz at python.org></dd> <dt class="field-even">Discussions-To:</dt> <dd class="field-even"><a class="reference external" href="https://mail.python.org/archives/list/python-dev@python.org/">Python-Dev 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="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-odd">Created:</dt> <dd class="field-odd">22-May-2013</dd> <dt class="field-even">Python-Version:</dt> <dd class="field-even">3.4</dd> <dt class="field-odd">Post-History:</dt> <dd class="field-odd">22-May-2013, 25-May-2013, 31-May-2013</dd> <dt class="field-even">Replaces:</dt> <dd class="field-even"><a class="reference external" href="../pep-0245/">245</a>, <a class="reference external" href="../pep-0246/">246</a>, <a class="reference external" href="../pep-3124/">3124</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="#rationale-and-goals">Rationale and Goals</a></li> <li><a class="reference internal" href="#user-api">User API</a></li> <li><a class="reference internal" href="#implementation-notes">Implementation Notes</a><ul> <li><a class="reference internal" href="#abstract-base-classes">Abstract Base Classes</a></li> </ul> </li> <li><a class="reference internal" href="#usage-patterns">Usage Patterns</a></li> <li><a class="reference internal" href="#alternative-approaches">Alternative approaches</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> This PEP proposes a new mechanism in the <code class="docutils literal notranslate">functools</code> standard library module that provides a simple form of generic programming known as single-dispatch generic functions. A generic function is composed of multiple functions implementing the same operation for different types. Which implementation should be used during a call is determined by the dispatch algorithm. When the implementation is chosen based on the type of a single argument, this is known as single dispatch. </section> <section id="rationale-and-goals"> <h2><a class="toc-backref" href="#rationale-and-goals" role="doc-backlink">Rationale and Goals</a></h2> Python has always provided a variety of built-in and standard-library generic functions, such as <code class="docutils literal notranslate">len()</code>, <code class="docutils literal notranslate">iter()</code>, <code class="docutils literal notranslate">pprint.pprint()</code>, <code class="docutils literal notranslate">copy.copy()</code>, and most of the functions in the <code class="docutils literal notranslate">operator</code> module. However, it currently: <ol class="arabic simple"> <li>does not have a simple or straightforward way for developers to create new generic functions,</li> <li>does not have a standard way for methods to be added to existing generic functions (i.e., some are added using registration functions, others require defining <code class="docutils literal notranslate">__special__</code> methods, possibly by monkeypatching).</li> </ol> In addition, it is currently a common anti-pattern for Python code to inspect the types of received arguments, in order to decide what to do with the objects. For example, code may wish to accept either an object of some type, or a sequence of objects of that type. Currently, the “obvious way” to do this is by type inspection, but this is brittle and closed to extension. Abstract Base Classes make it easier to discover present behaviour, but don’t help adding new behaviour. A developer using an already-written library may be unable to change how their objects are treated by such code, especially if the objects they are using were created by a third party. Therefore, this PEP proposes a uniform API to address dynamic overloading using decorators. </section> <section id="user-api"> <h2><a class="toc-backref" href="#user-api" role="doc-backlink">User API</a></h2> To define a generic function, decorate it with the <code class="docutils literal notranslate">@singledispatch</code> decorator. Note that the dispatch happens on the type of the first argument. Create your function accordingly: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> from functools import singledispatch >>> @singledispatch ... def fun(arg, verbose=False): ... if verbose: ... print("Let me just say,", end=" ") ... print(arg) </pre></div> </div> To add overloaded implementations to the function, use the <code class="docutils literal notranslate">register()</code> attribute of the generic function. This is a decorator, taking a type parameter and decorating a function implementing the operation for that type: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> @fun.register(int) ... def _(arg, verbose=False): ... if verbose: ... print("Strength in numbers, eh?", end=" ") ... print(arg) ... >>> @fun.register(list) ... def _(arg, verbose=False): ... if verbose: ... print("Enumerate this:") ... for i, elem in enumerate(arg): ... print(i, elem) </pre></div> </div> To enable registering lambdas and pre-existing functions, the <code class="docutils literal notranslate">register()</code> attribute can be used in a functional form: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> def nothing(arg, verbose=False): ... print("Nothing.") ... >>> fun.register(type(None), nothing) </pre></div> </div> The <code class="docutils literal notranslate">register()</code> attribute returns the undecorated function. This enables decorator stacking, pickling, as well as creating unit tests for each variant independently: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> @fun.register(float) ... @fun.register(Decimal) ... def fun_num(arg, verbose=False): ... if verbose: ... print("Half of your number:", end=" ") ... print(arg / 2) ... >>> fun_num is fun False </pre></div> </div> When called, the generic function dispatches on the type of the first argument: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> fun("Hello, world.") Hello, world. >>> fun("test.", verbose=True) Let me just say, test. >>> fun(42, verbose=True) Strength in numbers, eh? 42 >>> fun(['spam', 'spam', 'eggs', 'spam'], verbose=True) Enumerate this: 0 spam 1 spam 2 eggs 3 spam >>> fun(None) Nothing. >>> fun(1.23) 0.615 </pre></div> </div> Where there is no registered implementation for a specific type, its method resolution order is used to find a more generic implementation. The original function decorated with <code class="docutils literal notranslate">@singledispatch</code> is registered for the base <code class="docutils literal notranslate">object</code> type, which means it is used if no better implementation is found. To check which implementation will the generic function choose for a given type, use the <code class="docutils literal notranslate">dispatch()</code> attribute: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> fun.dispatch(float) <function fun_num at 0x104319058> >>> fun.dispatch(dict) # note: default implementation <function fun at 0x103fe0000> </pre></div> </div> To access all registered implementations, use the read-only <code class="docutils literal notranslate">registry</code> attribute: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> fun.registry.keys() dict_keys([<class 'NoneType'>, <class 'int'>, <class 'object'>, <class 'decimal.Decimal'>, <class 'list'>, <class 'float'>]) >>> fun.registry[float] <function fun_num at 0x1035a2840> >>> fun.registry[object] <function fun at 0x103fe0000> </pre></div> </div> The proposed API is intentionally limited and opinionated, as to ensure it is easy to explain and use, as well as to maintain consistency with existing members in the <code class="docutils literal notranslate">functools</code> module. </section> <section id="implementation-notes"> <h2><a class="toc-backref" href="#implementation-notes" role="doc-backlink">Implementation Notes</a></h2> The functionality described in this PEP is already implemented in the <code class="docutils literal notranslate">pkgutil</code> standard library module as <code class="docutils literal notranslate">simplegeneric</code>. Because this implementation is mature, the goal is to move it largely as-is. The reference implementation is available on hg.python.org <a class="footnote-reference brackets" href="#ref-impl" id="id1">[1]</a>. The dispatch type is specified as a decorator argument. An alternative form using function annotations was considered but its inclusion has been rejected. As of May 2013, this usage pattern is out of scope for the standard library <a class="footnote-reference brackets" href="#pep-0008" id="id2">[2]</a>, and the best practices for annotation usage are still debated. Based on the current <code class="docutils literal notranslate">pkgutil.simplegeneric</code> implementation, and following the convention on registering virtual subclasses on Abstract Base Classes, the dispatch registry will not be thread-safe. <section id="abstract-base-classes"> <h3><a class="toc-backref" href="#abstract-base-classes" role="doc-backlink">Abstract Base Classes</a></h3> The <code class="docutils literal notranslate">pkgutil.simplegeneric</code> implementation relied on several forms of method resolution order (MRO). <code class="docutils literal notranslate">@singledispatch</code> removes special handling of old-style classes and Zope’s ExtensionClasses. More importantly, it introduces support for Abstract Base Classes (ABC). When a generic function implementation is registered for an ABC, the dispatch algorithm switches to an extended form of C3 linearization, which includes the relevant ABCs in the MRO of the provided argument. The algorithm inserts ABCs where their functionality is introduced, i.e. <code class="docutils literal notranslate">issubclass(cls, abc)</code> returns <code class="docutils literal notranslate">True</code> for the class itself but returns <code class="docutils literal notranslate">False</code> for all its direct base classes. Implicit ABCs for a given class (either registered or inferred from the presence of a special method like <code class="docutils literal notranslate">__len__()</code>) are inserted directly after the last ABC explicitly listed in the MRO of said class. In its most basic form, this linearization returns the MRO for the given type: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> _compose_mro(dict, []) [<class 'dict'>, <class 'object'>] </pre></div> </div> When the second argument contains ABCs that the specified type is a subclass of, they are inserted in a predictable order: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> _compose_mro(dict, [Sized, MutableMapping, str, ... Sequence, Iterable]) [<class 'dict'>, <class 'collections.abc.MutableMapping'>, <class 'collections.abc.Mapping'>, <class 'collections.abc.Sized'>, <class 'collections.abc.Iterable'>, <class 'collections.abc.Container'>, <class 'object'>] </pre></div> </div> While this mode of operation is significantly slower, all dispatch decisions are cached. The cache is invalidated on registering new implementations on the generic function or when user code calls <code class="docutils literal notranslate">register()</code> on an ABC to implicitly subclass it. In the latter case, it is possible to create a situation with ambiguous dispatch, for instance: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> from collections.abc import Iterable, Container >>> class P: ... pass >>> Iterable.register(P) <class '__main__.P'> >>> Container.register(P) <class '__main__.P'> </pre></div> </div> Faced with ambiguity, <code class="docutils literal notranslate">@singledispatch</code> refuses the temptation to guess: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> @singledispatch ... def g(arg): ... return "base" ... >>> g.register(Iterable, lambda arg: "iterable") <function <lambda> at 0x108b49110> >>> g.register(Container, lambda arg: "container") <function <lambda> at 0x108b491c8> >>> g(P()) Traceback (most recent call last): ... RuntimeError: Ambiguous dispatch: <class 'collections.abc.Container'> or <class 'collections.abc.Iterable'> </pre></div> </div> Note that this exception would not be raised if one or more ABCs had been provided explicitly as base classes during class definition. In this case dispatch happens in the MRO order: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> class Ten(Iterable, Container): ... def __iter__(self): ... for i in range(10): ... yield i ... def __contains__(self, value): ... return value in range(10) ... >>> g(Ten()) 'iterable' </pre></div> </div> A similar conflict arises when subclassing an ABC is inferred from the presence of a special method like <code class="docutils literal notranslate">__len__()</code> or <code class="docutils literal notranslate">__contains__()</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> class Q: ... def __contains__(self, value): ... return False ... >>> issubclass(Q, Container) True >>> Iterable.register(Q) >>> g(Q()) Traceback (most recent call last): ... RuntimeError: Ambiguous dispatch: <class 'collections.abc.Container'> or <class 'collections.abc.Iterable'> </pre></div> </div> An early version of the PEP contained a custom approach that was simpler but created a number of edge cases with surprising results <a class="footnote-reference brackets" href="#why-c3" id="id3">[3]</a>. </section> </section> <section id="usage-patterns"> <h2><a class="toc-backref" href="#usage-patterns" role="doc-backlink">Usage Patterns</a></h2> This PEP proposes extending behaviour only of functions specifically marked as generic. Just as a base class method may be overridden by a subclass, so too a function may be overloaded to provide custom functionality for a given type. Universal overloading does not equal arbitrary overloading, in the sense that we need not expect people to randomly redefine the behavior of existing functions in unpredictable ways. To the contrary, generic function usage in actual programs tends to follow very predictable patterns and registered implementations are highly-discoverable in the common case. If a module is defining a new generic operation, it will usually also define any required implementations for existing types in the same place. Likewise, if a module is defining a new type, then it will usually define implementations there for any generic functions that it knows or cares about. As a result, the vast majority of registered implementations can be found adjacent to either the function being overloaded, or to a newly-defined type for which the implementation is adding support. It is only in rather infrequent cases that one will have implementations registered in a module that contains neither the function nor the type(s) for which the implementation is added. In the absence of incompetence or deliberate intention to be obscure, the few implementations that are not registered adjacent to the relevant type(s) or function(s), will generally not need to be understood or known about outside the scope where those implementations are defined. (Except in the “support modules” case, where best practice suggests naming them accordingly.) As mentioned earlier, single-dispatch generics are already prolific throughout the standard library. A clean, standard way of doing them provides a way forward to refactor those custom implementations to use a common one, opening them up for user extensibility at the same time. </section> <section id="alternative-approaches"> <h2><a class="toc-backref" href="#alternative-approaches" role="doc-backlink">Alternative approaches</a></h2> In <a class="pep reference internal" href="../pep-3124/" title="PEP 3124 – Overloading, Generic Functions, Interfaces, and Adaptation">PEP 3124</a> Phillip J. Eby proposes a full-grown solution with overloading based on arbitrary rule sets (with the default implementation dispatching on argument types), as well as interfaces, adaptation and method combining. PEAK-Rules <a class="footnote-reference brackets" href="#peak-rules" id="id4">[4]</a> is a reference implementation of the concepts described in PJE’s PEP. Such a broad approach is inherently complex, which makes reaching a consensus hard. In contrast, this PEP focuses on a single piece of functionality that is simple to reason about. It’s important to note this does not preclude the use of other approaches now or in the future. In a 2005 article on Artima <a class="footnote-reference brackets" href="#artima2005" id="id5">[5]</a> Guido van Rossum presents a generic function implementation that dispatches on types of all arguments on a function. The same approach was chosen in Andrey Popp’s <code class="docutils literal notranslate">generic</code> package available on PyPI <a class="footnote-reference brackets" href="#pypi-generic" id="id6">[6]</a>, as well as David Mertz’s <code class="docutils literal notranslate">gnosis.magic.multimethods</code> <a class="footnote-reference brackets" href="#gnosis-multimethods" id="id7">[7]</a>. While this seems desirable at first, I agree with Fredrik Lundh’s comment that “if you design APIs with pages of logic just to sort out what code a function should execute, you should probably hand over the API design to someone else”. In other words, the single argument approach proposed in this PEP is not only easier to implement but also clearly communicates that dispatching on a more complex state is an anti-pattern. It also has the virtue of corresponding directly with the familiar method dispatch mechanism in object oriented programming. The only difference is whether the custom implementation is associated more closely with the data (object-oriented methods) or the algorithm (single-dispatch overloading). PyPy’s RPython offers <code class="docutils literal notranslate">extendabletype</code> <a class="footnote-reference brackets" href="#pairtype" id="id8">[8]</a>, a metaclass which enables classes to be externally extended. In combination with <code class="docutils literal notranslate">pairtype()</code> and <code class="docutils literal notranslate">pair()</code> factories, this offers a form of single-dispatch generics. </section> <section id="acknowledgements"> <h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2> Apart from Phillip J. Eby’s work on <a class="pep reference internal" href="../pep-3124/" title="PEP 3124 – Overloading, Generic Functions, Interfaces, and Adaptation">PEP 3124</a> and PEAK-Rules, influences include Paul Moore’s original issue <a class="footnote-reference brackets" href="#issue-5135" id="id9">[9]</a> that proposed exposing <code class="docutils literal notranslate">pkgutil.simplegeneric</code> as part of the <code class="docutils literal notranslate">functools</code> API, Guido van Rossum’s article on multimethods <a class="footnote-reference brackets" href="#artima2005" id="id10">[5]</a>, and discussions with Raymond Hettinger on a general pprint rewrite. Huge thanks to Alyssa Coghlan for encouraging me to create this PEP and providing initial feedback. </section> <section id="references"> <h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2> <aside class="footnote-list brackets"> <aside class="footnote brackets" id="ref-impl" role="doc-footnote"> <dt class="label" id="ref-impl">[<a href="#id1">1</a>]</dt> <dd><a class="reference external" href="http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l359">http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l359</a></aside> <aside class="footnote brackets" id="pep-0008" role="doc-footnote"> <dt class="label" id="pep-0008">[<a href="#id2">2</a>]</dt> <dd><a class="pep reference internal" href="../pep-0008/" title="PEP 8 – Style Guide for Python Code">PEP 8</a> states in the “Programming Recommendations” section that “the Python standard library will not use function annotations as that would result in a premature commitment to a particular annotation style”.</aside> <aside class="footnote brackets" id="why-c3" role="doc-footnote"> <dt class="label" id="why-c3">[<a href="#id3">3</a>]</dt> <dd><a class="reference external" href="http://bugs.python.org/issue18244">http://bugs.python.org/issue18244</a></aside> <aside class="footnote brackets" id="peak-rules" role="doc-footnote"> <dt class="label" id="peak-rules">[<a href="#id4">4</a>]</dt> <dd><a class="reference external" href="http://peak.telecommunity.com/DevCenter/PEAK_2dRules">http://peak.telecommunity.com/DevCenter/PEAK_2dRules</a></aside> <aside class="footnote brackets" id="artima2005" role="doc-footnote"> <dt class="label" id="artima2005">[5] (<a href='#id5'>1</a>, <a href='#id10'>2</a>) </dt> <dd><a class="reference external" href="http://www.artima.com/weblogs/viewpost.jsp?thread=101605">http://www.artima.com/weblogs/viewpost.jsp?thread=101605</a></aside> <aside class="footnote brackets" id="pypi-generic" role="doc-footnote"> <dt class="label" id="pypi-generic">[<a href="#id6">6</a>]</dt> <dd><a class="reference external" href="http://pypi.python.org/pypi/generic">http://pypi.python.org/pypi/generic</a></aside> <aside class="footnote brackets" id="gnosis-multimethods" role="doc-footnote"> <dt class="label" id="gnosis-multimethods">[<a href="#id7">7</a>]</dt> <dd><a class="reference external" href="http://gnosis.cx/publish/programming/charming_python_b12.html">http://gnosis.cx/publish/programming/charming_python_b12.html</a></aside> <aside class="footnote brackets" id="pairtype" role="doc-footnote"> <dt class="label" id="pairtype">[<a href="#id8">8</a>]</dt> <dd><a class="reference external" href="https://bitbucket.org/pypy/pypy/raw/default/rpython/tool/pairtype.py">https://bitbucket.org/pypy/pypy/raw/default/rpython/tool/pairtype.py</a></aside> <aside class="footnote brackets" id="issue-5135" role="doc-footnote"> <dt class="label" id="issue-5135">[<a href="#id9">9</a>]</dt> <dd><a class="reference external" href="http://bugs.python.org/issue5135">http://bugs.python.org/issue5135</a></aside> </aside> </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> This document has been placed in the public domain. </section> </section> <hr class="docutils" /> Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0443.rst">https://github.com/python/peps/blob/main/peps/pep-0443.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0443.rst">2023-10-11 12:05:51 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="#rationale-and-goals">Rationale and Goals</a></li> <li><a class="reference internal" href="#user-api">User API</a></li> <li><a class="reference internal" href="#implementation-notes">Implementation Notes</a><ul> <li><a class="reference internal" href="#abstract-base-classes">Abstract Base Classes</a></li> </ul> </li> <li><a class="reference internal" href="#usage-patterns">Usage Patterns</a></li> <li><a class="reference internal" href="#alternative-approaches">Alternative approaches</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#references">References</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-0443.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>