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 3141 – A Type Hierarchy for Numbers | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-3141/"> <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 3141 – A Type Hierarchy for Numbers | peps.python.org'> <meta property="og:description" content="This proposal defines a hierarchy of Abstract Base Classes (ABCs) (PEP 3119) to represent number-like classes. It proposes a hierarchy of Number :> Complex :> Real :> Rational :> Integral where A :> B means “A is a supertype of B”. The hierarchy is insp..."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-3141/"> <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 proposal defines a hierarchy of Abstract Base Classes (ABCs) (PEP 3119) to represent number-like classes. It proposes a hierarchy of Number :> Complex :> Real :> Rational :> Integral where A :> B means “A is a supertype of B”. The hierarchy is insp..."> <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 3141</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 3141 – A Type Hierarchy for Numbers</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Jeffrey Yasskin <jyasskin at google.com></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">Created:</dt> <dd class="field-even">23-Apr-2007</dd> <dt class="field-odd">Python-Version:</dt> <dd class="field-odd">3.0</dd> <dt class="field-even">Post-History:</dt> <dd class="field-even">25-Apr-2007, 16-May-2007, 02-Aug-2007</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">Rationale</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#numeric-classes">Numeric Classes</a></li> <li><a class="reference internal" href="#changes-to-operations-and-magic-methods">Changes to operations and __magic__ methods</a></li> <li><a class="reference internal" href="#notes-for-type-implementors">Notes for type implementors</a><ul> <li><a class="reference internal" href="#adding-more-numeric-abcs">Adding More Numeric ABCs</a></li> <li><a class="reference internal" href="#implementing-the-arithmetic-operations">Implementing the arithmetic operations</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#rejected-alternatives">Rejected Alternatives</a></li> <li><a class="reference internal" href="#the-decimal-type">The Decimal Type</a></li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</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 proposal defines a hierarchy of Abstract Base Classes (ABCs) (PEP 3119) to represent number-like classes. It proposes a hierarchy of <code class="docutils literal notranslate">Number :> Complex :> Real :> Rational :> Integral</code> where <code class="docutils literal notranslate">A :> B</code> means “A is a supertype of B”. The hierarchy is inspired by Scheme’s numeric tower <a class="footnote-reference brackets" href="#schemetower" id="id1">[2]</a>. </section> <section id="rationale"> <h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2> Functions that take numbers as arguments should be able to determine the properties of those numbers, and if and when overloading based on types is added to the language, should be overloadable based on the types of the arguments. For example, slicing requires its arguments to be <code class="docutils literal notranslate">Integrals</code>, and the functions in the <code class="docutils literal notranslate">math</code> module require their arguments to be <code class="docutils literal notranslate">Real</code>. </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> This PEP specifies a set of Abstract Base Classes, and suggests a general strategy for implementing some of the methods. It uses terminology from <a class="pep reference internal" href="../pep-3119/" title="PEP 3119 – Introducing Abstract Base Classes">PEP 3119</a>, but the hierarchy is intended to be meaningful for any systematic method of defining sets of classes. The type checks in the standard library should use these classes instead of the concrete built-ins. <section id="numeric-classes"> <h3><a class="toc-backref" href="#numeric-classes" role="doc-backlink">Numeric Classes</a></h3> We begin with a Number class to make it easy for people to be fuzzy about what kind of number they expect. This class only helps with overloading; it doesn’t provide any operations. <div class="highlight-default notranslate"><div class="highlight"><pre>class Number(metaclass=ABCMeta): pass </pre></div> </div> Most implementations of complex numbers will be hashable, but if you need to rely on that, you’ll have to check it explicitly: mutable numbers are supported by this hierarchy. <div class="highlight-default notranslate"><div class="highlight"><pre>class Complex(Number): """Complex defines the operations that work on the builtin complex type. In short, those are: conversion to complex, bool(), .real, .imag, +, -, *, /, **, abs(), .conjugate(), ==, and !=. If it is given heterogeneous arguments, and doesn't have special knowledge about them, it should fall back to the builtin complex type as described below. """ @abstractmethod def __complex__(self): """Return a builtin complex instance.""" def __bool__(self): """True if self != 0.""" return self != 0 @abstractproperty def real(self): """Retrieve the real component of this number. This should subclass Real. """ raise NotImplementedError @abstractproperty def imag(self): """Retrieve the imaginary component of this number. This should subclass Real. """ raise NotImplementedError @abstractmethod def __add__(self, other): raise NotImplementedError @abstractmethod def __radd__(self, other): raise NotImplementedError @abstractmethod def __neg__(self): raise NotImplementedError def __pos__(self): """Coerces self to whatever class defines the method.""" raise NotImplementedError def __sub__(self, other): return self + -other def __rsub__(self, other): return -self + other @abstractmethod def __mul__(self, other): raise NotImplementedError @abstractmethod def __rmul__(self, other): raise NotImplementedError @abstractmethod def __div__(self, other): """a/b; should promote to float or complex when necessary.""" raise NotImplementedError @abstractmethod def __rdiv__(self, other): raise NotImplementedError @abstractmethod def __pow__(self, exponent): """a**b; should promote to float or complex when necessary.""" raise NotImplementedError @abstractmethod def __rpow__(self, base): raise NotImplementedError @abstractmethod def __abs__(self): """Returns the Real distance from 0.""" raise NotImplementedError @abstractmethod def conjugate(self): """(x+y*i).conjugate() returns (x-y*i).""" raise NotImplementedError @abstractmethod def __eq__(self, other): raise NotImplementedError # __ne__ is inherited from object and negates whatever __eq__ does. </pre></div> </div> The <code class="docutils literal notranslate">Real</code> ABC indicates that the value is on the real line, and supports the operations of the <code class="docutils literal notranslate">float</code> builtin. Real numbers are totally ordered except for NaNs (which this PEP basically ignores). <div class="highlight-default notranslate"><div class="highlight"><pre>class Real(Complex): """To Complex, Real adds the operations that work on real numbers. In short, those are: conversion to float, trunc(), math.floor(), math.ceil(), round(), divmod(), //, %, <, <=, >, and >=. Real also provides defaults for some of the derived operations. """ # XXX What to do about the __int__ implementation that's # currently present on float? Get rid of it? @abstractmethod def __float__(self): """Any Real can be converted to a native float object.""" raise NotImplementedError @abstractmethod def __trunc__(self): """Truncates self to an Integral. Returns an Integral i such that: * i>=0 iff self>0; * abs(i) <= abs(self); * for any Integral j satisfying the first two conditions, abs(i) >= abs(j) [i.e. i has "maximal" abs among those]. i.e. "truncate towards 0". """ raise NotImplementedError @abstractmethod def __floor__(self): """Finds the greatest Integral <= self.""" raise NotImplementedError @abstractmethod def __ceil__(self): """Finds the least Integral >= self.""" raise NotImplementedError @abstractmethod def __round__(self, ndigits:Integral=None): """Rounds self to ndigits decimal places, defaulting to 0. If ndigits is omitted or None, returns an Integral, otherwise returns a Real, preferably of the same type as self. Types may choose which direction to round half. For example, float rounds half toward even. """ raise NotImplementedError def __divmod__(self, other): """The pair (self // other, self % other). Sometimes this can be computed faster than the pair of operations. """ return (self // other, self % other) def __rdivmod__(self, other): """The pair (self // other, self % other). Sometimes this can be computed faster than the pair of operations. """ return (other // self, other % self) @abstractmethod def __floordiv__(self, other): """The floor() of self/other. Integral.""" raise NotImplementedError @abstractmethod def __rfloordiv__(self, other): """The floor() of other/self.""" raise NotImplementedError @abstractmethod def __mod__(self, other): """self % other See https://mail.python.org/pipermail/python-3000/2006-May/001735.html and consider using "self/other - trunc(self/other)" instead if you're worried about round-off errors. """ raise NotImplementedError @abstractmethod def __rmod__(self, other): """other % self""" raise NotImplementedError @abstractmethod def __lt__(self, other): """< on Reals defines a total ordering, except perhaps for NaN.""" raise NotImplementedError @abstractmethod def __le__(self, other): raise NotImplementedError # __gt__ and __ge__ are automatically done by reversing the arguments. # (But __le__ is not computed as the opposite of __gt__!) # Concrete implementations of Complex abstract methods. # Subclasses may override these, but don't have to. def __complex__(self): return complex(float(self)) @property def real(self): return +self @property def imag(self): return 0 def conjugate(self): """Conjugate is a no-op for Reals.""" return +self </pre></div> </div> We should clean up Demo/classes/Rat.py and promote it into rational.py in the standard library. Then it will implement the Rational ABC. <div class="highlight-default notranslate"><div class="highlight"><pre>class Rational(Real, Exact): """.numerator and .denominator should be in lowest terms.""" @abstractproperty def numerator(self): raise NotImplementedError @abstractproperty def denominator(self): raise NotImplementedError # Concrete implementation of Real's conversion to float. # (This invokes Integer.__div__().) def __float__(self): return self.numerator / self.denominator </pre></div> </div> And finally integers: <div class="highlight-default notranslate"><div class="highlight"><pre>class Integral(Rational): """Integral adds a conversion to int and the bit-string operations.""" @abstractmethod def __int__(self): raise NotImplementedError def __index__(self): """__index__() exists because float has __int__().""" return int(self) def __lshift__(self, other): return int(self) << int(other) def __rlshift__(self, other): return int(other) << int(self) def __rshift__(self, other): return int(self) >> int(other) def __rrshift__(self, other): return int(other) >> int(self) def __and__(self, other): return int(self) & int(other) def __rand__(self, other): return int(other) & int(self) def __xor__(self, other): return int(self) ^ int(other) def __rxor__(self, other): return int(other) ^ int(self) def __or__(self, other): return int(self) | int(other) def __ror__(self, other): return int(other) | int(self) def __invert__(self): return ~int(self) # Concrete implementations of Rational and Real abstract methods. def __float__(self): """float(self) == float(int(self))""" return float(int(self)) @property def numerator(self): """Integers are their own numerators.""" return +self @property def denominator(self): """Integers have a denominator of 1.""" return 1 </pre></div> </div> </section> <section id="changes-to-operations-and-magic-methods"> <h3><a class="toc-backref" href="#changes-to-operations-and-magic-methods" role="doc-backlink">Changes to operations and __magic__ methods</a></h3> To support more precise narrowing from float to int (and more generally, from Real to Integral), we propose the following new __magic__ methods, to be called from the corresponding library functions. All of these return Integrals rather than Reals. <ol class="arabic simple"> <li><code class="docutils literal notranslate">__trunc__(self)</code>, called from a new builtin <code class="docutils literal notranslate">trunc(x)</code>, which returns the Integral closest to <code class="docutils literal notranslate">x</code> between 0 and <code class="docutils literal notranslate">x</code>.</li> <li><code class="docutils literal notranslate">__floor__(self)</code>, called from <code class="docutils literal notranslate">math.floor(x)</code>, which returns the greatest Integral <code class="docutils literal notranslate"><= x</code>.</li> <li><code class="docutils literal notranslate">__ceil__(self)</code>, called from <code class="docutils literal notranslate">math.ceil(x)</code>, which returns the least Integral <code class="docutils literal notranslate">>= x</code>.</li> <li><code class="docutils literal notranslate">__round__(self)</code>, called from <code class="docutils literal notranslate">round(x)</code>, which returns the Integral closest to <code class="docutils literal notranslate">x</code>, rounding half as the type chooses. <code class="docutils literal notranslate">float</code> will change in 3.0 to round half toward even. There is also a 2-argument version, <code class="docutils literal notranslate">__round__(self, ndigits)</code>, called from <code class="docutils literal notranslate">round(x, ndigits)</code>, which should return a Real.</li> </ol> In 2.6, <code class="docutils literal notranslate">math.floor</code>, <code class="docutils literal notranslate">math.ceil</code>, and <code class="docutils literal notranslate">round</code> will continue to return floats. The <code class="docutils literal notranslate">int()</code> conversion implemented by <code class="docutils literal notranslate">float</code> is equivalent to <code class="docutils literal notranslate">trunc()</code>. In general, the <code class="docutils literal notranslate">int()</code> conversion should try <code class="docutils literal notranslate">__int__()</code> first and if it is not found, try <code class="docutils literal notranslate">__trunc__()</code>. <code class="docutils literal notranslate">complex.__{divmod,mod,floordiv,int,float}__</code> also go away. It would be nice to provide a nice error message to help confused porters, but not appearing in <code class="docutils literal notranslate">help(complex)</code> is more important. </section> <section id="notes-for-type-implementors"> <h3><a class="toc-backref" href="#notes-for-type-implementors" role="doc-backlink">Notes for type implementors</a></h3> Implementors should be careful to make equal numbers equal and hash them to the same values. This may be subtle if there are two different extensions of the real numbers. For example, a complex type could reasonably implement hash() as follows: <div class="highlight-default notranslate"><div class="highlight"><pre>def __hash__(self): return hash(complex(self)) </pre></div> </div> but should be careful of any values that fall outside of the built in complex’s range or precision. <section id="adding-more-numeric-abcs"> <h4><a class="toc-backref" href="#adding-more-numeric-abcs" role="doc-backlink">Adding More Numeric ABCs</a></h4> There are, of course, more possible ABCs for numbers, and this would be a poor hierarchy if it precluded the possibility of adding those. You can add <code class="docutils literal notranslate">MyFoo</code> between <code class="docutils literal notranslate">Complex</code> and <code class="docutils literal notranslate">Real</code> with: <div class="highlight-default notranslate"><div class="highlight"><pre>class MyFoo(Complex): ... MyFoo.register(Real) </pre></div> </div> </section> <section id="implementing-the-arithmetic-operations"> <h4><a class="toc-backref" href="#implementing-the-arithmetic-operations" role="doc-backlink">Implementing the arithmetic operations</a></h4> We want to implement the arithmetic operations so that mixed-mode operations either call an implementation whose author knew about the types of both arguments, or convert both to the nearest built in type and do the operation there. For subtypes of Integral, this means that __add__ and __radd__ should be defined as: <div class="highlight-default notranslate"><div class="highlight"><pre>class MyIntegral(Integral): def __add__(self, other): if isinstance(other, MyIntegral): return do_my_adding_stuff(self, other) elif isinstance(other, OtherTypeIKnowAbout): return do_my_other_adding_stuff(self, other) else: return NotImplemented def __radd__(self, other): if isinstance(other, MyIntegral): return do_my_adding_stuff(other, self) elif isinstance(other, OtherTypeIKnowAbout): return do_my_other_adding_stuff(other, self) elif isinstance(other, Integral): return int(other) + int(self) elif isinstance(other, Real): return float(other) + float(self) elif isinstance(other, Complex): return complex(other) + complex(self) else: return NotImplemented </pre></div> </div> There are 5 different cases for a mixed-type operation on subclasses of Complex. I’ll refer to all of the above code that doesn’t refer to MyIntegral and OtherTypeIKnowAbout as “boilerplate”. <code class="docutils literal notranslate">a</code> will be an instance of <code class="docutils literal notranslate">A</code>, which is a subtype of <code class="docutils literal notranslate">Complex</code> (<code class="docutils literal notranslate">a : A <: Complex</code>), and <code class="docutils literal notranslate">b : B <: Complex</code>. I’ll consider <code class="docutils literal notranslate">a + b</code>: <ol class="arabic simple"> <li>If A defines an __add__ which accepts b, all is well.</li> <li>If A falls back to the boilerplate code, and it were to return a value from __add__, we’d miss the possibility that B defines a more intelligent __radd__, so the boilerplate should return NotImplemented from __add__. (Or A may not implement __add__ at all.)</li> <li>Then B’s __radd__ gets a chance. If it accepts a, all is well.</li> <li>If it falls back to the boilerplate, there are no more possible methods to try, so this is where the default implementation should live.</li> <li>If B <: A, Python tries B.__radd__ before A.__add__. This is ok, because it was implemented with knowledge of A, so it can handle those instances before delegating to Complex.</li> </ol> If <code class="docutils literal notranslate">A<:Complex</code> and <code class="docutils literal notranslate">B<:Real</code> without sharing any other knowledge, then the appropriate shared operation is the one involving the built in complex, and both __radd__s land there, so <code class="docutils literal notranslate">a+b == b+a</code>. </section> </section> </section> <section id="rejected-alternatives"> <h2><a class="toc-backref" href="#rejected-alternatives" role="doc-backlink">Rejected Alternatives</a></h2> The initial version of this PEP defined an algebraic hierarchy inspired by a Haskell Numeric Prelude <a class="footnote-reference brackets" href="#numericprelude" id="id2">[1]</a> including MonoidUnderPlus, AdditiveGroup, Ring, and Field, and mentioned several other possible algebraic types before getting to the numbers. We had expected this to be useful to people using vectors and matrices, but the NumPy community really wasn’t interested, and we ran into the issue that even if <code class="docutils literal notranslate">x</code> is an instance of <code class="docutils literal notranslate">X <: MonoidUnderPlus</code> and <code class="docutils literal notranslate">y</code> is an instance of <code class="docutils literal notranslate">Y <: MonoidUnderPlus</code>, <code class="docutils literal notranslate">x + y</code> may still not make sense. Then we gave the numbers a much more branching structure to include things like the Gaussian Integers and Z/nZ, which could be Complex but wouldn’t necessarily support things like division. The community decided that this was too much complication for Python, so I’ve now scaled back the proposal to resemble the Scheme numeric tower much more closely. </section> <section id="the-decimal-type"> <h2><a class="toc-backref" href="#the-decimal-type" role="doc-backlink">The Decimal Type</a></h2> After consultation with its authors it has been decided that the <code class="docutils literal notranslate">Decimal</code> type should not at this time be made part of the numeric tower. </section> <section id="references"> <h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2> <ul class="simple"> <li><dl class="simple"> <dt>Possible Python 3K Class Tree?, wiki page by Bill Janssen</dt><dd>(<a class="reference external" href="https://wiki.python.org/moin/AbstractBaseClasses">https://wiki.python.org/moin/AbstractBaseClasses</a>)</dd> </dl> </li> </ul> <aside class="footnote-list brackets"> <aside class="footnote brackets" id="numericprelude" role="doc-footnote"> <dt class="label" id="numericprelude">[<a href="#id2">1</a>]</dt> <dd>NumericPrelude: An experimental alternative hierarchy of numeric type classes (<a class="reference external" href="https://archives.haskell.org/code.haskell.org/numeric-prelude/docs/html/index.html">https://archives.haskell.org/code.haskell.org/numeric-prelude/docs/html/index.html</a>)</aside> <aside class="footnote brackets" id="schemetower" role="doc-footnote"> <dt class="label" id="schemetower">[<a href="#id1">2</a>]</dt> <dd>The Scheme numerical tower (<a class="reference external" href="https://groups.csail.mit.edu/mac/ftpdir/scheme-reports/r5rs-html/r5rs_8.html#SEC50">https://groups.csail.mit.edu/mac/ftpdir/scheme-reports/r5rs-html/r5rs_8.html#SEC50</a>)</aside> </aside> </section> <section id="acknowledgements"> <h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2> Thanks to Neal Norwitz for encouraging me to write this PEP in the first place, to Travis Oliphant for pointing out that the numpy people didn’t really care about the algebraic concepts, to Alan Isaac for reminding me that Scheme had already done this, and to Guido van Rossum and lots of other people on the mailing list for refining the concept. </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-3141.rst">https://github.com/python/peps/blob/main/peps/pep-3141.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-3141.rst">2025-01-30 01:21: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">Rationale</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#numeric-classes">Numeric Classes</a></li> <li><a class="reference internal" href="#changes-to-operations-and-magic-methods">Changes to operations and __magic__ methods</a></li> <li><a class="reference internal" href="#notes-for-type-implementors">Notes for type implementors</a><ul> <li><a class="reference internal" href="#adding-more-numeric-abcs">Adding More Numeric ABCs</a></li> <li><a class="reference internal" href="#implementing-the-arithmetic-operations">Implementing the arithmetic operations</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#rejected-alternatives">Rejected Alternatives</a></li> <li><a class="reference internal" href="#the-decimal-type">The Decimal Type</a></li> <li><a class="reference internal" href="#references">References</a></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-3141.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>