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 335 – Overloadable Boolean Operators | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0335/"> <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 335 – Overloadable Boolean Operators | peps.python.org'> <meta property="og:description" content="This PEP proposes an extension to permit objects to define their own meanings for the boolean operators ‘and’, ‘or’ and ‘not’, and suggests an efficient strategy for implementation. A prototype of this implementation is available for download."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0335/"> <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 an extension to permit objects to define their own meanings for the boolean operators ‘and’, ‘or’ and ‘not’, and suggests an efficient strategy for implementation. A prototype of this implementation is available for download."> <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 335</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 335 – Overloadable Boolean Operators</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Gregory Ewing <greg.ewing at canterbury.ac.nz></dd> <dt class="field-even">Status:</dt> <dd class="field-even"><abbr title="Formally declined and will not be accepted">Rejected</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">29-Aug-2004</dd> <dt class="field-odd">Python-Version:</dt> <dd class="field-odd">3.3</dd> <dt class="field-even">Post-History:</dt> <dd class="field-even">05-Sep-2004, 30-Sep-2011, 25-Oct-2011</dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#rejection-notice">Rejection Notice</a></li> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#background">Background</a></li> <li><a class="reference internal" href="#motivation">Motivation</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="#special-methods">Special Methods</a></li> <li><a class="reference internal" href="#bytecodes">Bytecodes</a></li> <li><a class="reference internal" href="#type-slots">Type Slots</a></li> <li><a class="reference internal" href="#python-c-api-functions">Python/C API Functions</a></li> </ul> </li> <li><a class="reference internal" href="#alternatives-and-optimisations">Alternatives and Optimisations</a><ul> <li><a class="reference internal" href="#reduced-special-method-set">Reduced special method set</a></li> <li><a class="reference internal" href="#additional-bytecodes">Additional bytecodes</a></li> <li><a class="reference internal" href="#optimisation-of-not">Optimisation of ‘not’</a></li> </ul> </li> <li><a class="reference internal" href="#usage-examples">Usage Examples</a><ul> <li><a class="reference internal" href="#example-1-numpy-arrays">Example 1: NumPy Arrays</a></li> <li><a class="reference internal" href="#example-1-output">Example 1 Output</a></li> <li><a class="reference internal" href="#example-2-database-queries">Example 2: Database Queries</a></li> <li><a class="reference internal" href="#example-2-output">Example 2 Output</a></li> </ul> </li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <section id="rejection-notice"> <h2><a class="toc-backref" href="#rejection-notice" role="doc-backlink">Rejection Notice</a></h2> This PEP was rejected. See <a class="reference external" href="https://mail.python.org/pipermail/python-dev/2012-March/117510.html">https://mail.python.org/pipermail/python-dev/2012-March/117510.html</a> </section> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> This PEP proposes an extension to permit objects to define their own meanings for the boolean operators ‘and’, ‘or’ and ‘not’, and suggests an efficient strategy for implementation. A prototype of this implementation is available for download. </section> <section id="background"> <h2><a class="toc-backref" href="#background" role="doc-backlink">Background</a></h2> Python does not currently provide any ‘__xxx__’ special methods corresponding to the ‘and’, ‘or’ and ‘not’ boolean operators. In the case of ‘and’ and ‘or’, the most likely reason is that these operators have short-circuiting semantics, i.e. the second operand is not evaluated if the result can be determined from the first operand. The usual technique of providing special methods for these operators therefore would not work. There is no such difficulty in the case of ‘not’, however, and it would be straightforward to provide a special method for this operator. The rest of this proposal will therefore concentrate mainly on providing a way to overload ‘and’ and ‘or’. </section> <section id="motivation"> <h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2> There are many applications in which it is natural to provide custom meanings for Python operators, and in some of these, having boolean operators excluded from those able to be customised can be inconvenient. Examples include: <ol class="arabic"> <li>NumPy, in which almost all the operators are defined on arrays so as to perform the appropriate operation between corresponding elements, and return an array of the results. For consistency, one would expect a boolean operation between two arrays to return an array of booleans, but this is not currently possible.There is a precedent for an extension of this kind: comparison operators were originally restricted to returning boolean results, and rich comparisons were added so that comparisons of NumPy arrays could return arrays of booleans. </li> <li>A symbolic algebra system, in which a Python expression is evaluated in an environment which results in it constructing a tree of objects corresponding to the structure of the expression.</li> <li>A relational database interface, in which a Python expression is used to construct an SQL query.</li> </ol> A workaround often suggested is to use the bitwise operators ‘&’, ‘|’ and ‘~’ in place of ‘and’, ‘or’ and ‘not’, but this has some drawbacks: <ul class="simple"> <li>The precedence of these is different in relation to the other operators, and they may already be in use for other purposes (as in example 1).</li> <li>It is aesthetically displeasing to force users to use something other than the most obvious syntax for what they are trying to express. This would be particularly acute in the case of example 3, considering that boolean operations are a staple of SQL queries.</li> <li>Bitwise operators do not provide a solution to the problem of chained comparisons such as ‘a < b < c’ which involve an implicit ‘and’ operation. Such expressions currently cannot be used at all on data types such as NumPy arrays where the result of a comparison cannot be treated as having normal boolean semantics; they must be expanded into something like (a < b) & (b < c), losing a considerable amount of clarity.</li> </ul> </section> <section id="rationale"> <h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2> The requirements for a successful solution to the problem of allowing boolean operators to be customised are: <ol class="arabic simple"> <li>In the default case (where there is no customisation), the existing short-circuiting semantics must be preserved.</li> <li>There must not be any appreciable loss of speed in the default case.</li> <li>Ideally, the customisation mechanism should allow the object to provide either short-circuiting or non-short-circuiting semantics, at its discretion.</li> </ol> One obvious strategy, that has been previously suggested, is to pass into the special method the first argument and a function for evaluating the second argument. This would satisfy requirements 1 and 3, but not requirement 2, since it would incur the overhead of constructing a function object and possibly a Python function call on every boolean operation. Therefore, it will not be considered further here. The following section proposes a strategy that addresses all three requirements. A <a class="reference external" href="http://www.cosc.canterbury.ac.nz/~greg/python/obo//Python_OBO.tar.gz">prototype implementation</a> of this strategy is available for download. </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> <section id="special-methods"> <h3><a class="toc-backref" href="#special-methods" role="doc-backlink">Special Methods</a></h3> At the Python level, objects may define the following special methods. <table class="docutils align-default"> <thead> <tr class="row-odd"><th class="head">Unary</th> <th class="head">Binary, phase 1</th> <th class="head">Binary, phase 2</th> </tr> </thead> <tbody> <tr class="row-even"><td><ul class="simple"> <li>__not__(self)</li> </ul> </td> <td><ul class="simple"> <li>__and1__(self)</li> <li>__or1__(self)</li> </ul> </td> <td><ul class="simple"> <li>__and2__(self, other)</li> <li>__or2__(self, other)</li> <li>__rand2__(self, other)</li> <li>__ror2__(self, other)</li> </ul> </td> </tr> </tbody> </table> The __not__ method, if defined, implements the ‘not’ operator. If it is not defined, or it returns NotImplemented, existing semantics are used. To permit short-circuiting, processing of the ‘and’ and ‘or’ operators is split into two phases. Phase 1 occurs after evaluation of the first operand but before the second. If the first operand defines the relevant phase 1 method, it is called with the first operand as argument. If that method can determine the result without needing the second operand, it returns the result, and further processing is skipped. If the phase 1 method determines that the second operand is needed, it returns the special value NeedOtherOperand. This triggers the evaluation of the second operand, and the calling of a relevant phase 2 method. During phase 2, the __and2__/__rand2__ and __or2__/__ror2__ method pairs work as for other binary operators. Processing falls back to existing semantics if at any stage a relevant special method is not found or returns NotImplemented. As a special case, if the first operand defines a phase 2 method but no corresponding phase 1 method, the second operand is always evaluated and the phase 2 method called. This allows an object which does not want short-circuiting semantics to simply implement the phase 2 methods and ignore phase 1. </section> <section id="bytecodes"> <h3><a class="toc-backref" href="#bytecodes" role="doc-backlink">Bytecodes</a></h3> The patch adds four new bytecodes, LOGICAL_AND_1, LOGICAL_AND_2, LOGICAL_OR_1 and LOGICAL_OR_2. As an example of their use, the bytecode generated for an ‘and’ expression looks like this: <div class="highlight-default notranslate"><div class="highlight"><pre> . . . evaluate first operand LOGICAL_AND_1 L evaluate second operand LOGICAL_AND_2 L: . . . </pre></div> </div> The LOGICAL_AND_1 bytecode performs phase 1 processing. If it determines that the second operand is needed, it leaves the first operand on the stack and continues with the following code. Otherwise it pops the first operand, pushes the result and branches to L. The LOGICAL_AND_2 bytecode performs phase 2 processing, popping both operands and pushing the result. </section> <section id="type-slots"> <h3><a class="toc-backref" href="#type-slots" role="doc-backlink">Type Slots</a></h3> At the C level, the new special methods are manifested as five new slots in the type object. In the patch, they are added to the tp_as_number substructure, since this allows making use of some existing code for dealing with unary and binary operators. Their existence is signalled by a new type flag, Py_TPFLAGS_HAVE_BOOLEAN_OVERLOAD. The new type slots are: <div class="highlight-default notranslate"><div class="highlight"><pre>unaryfunc nb_logical_not; unaryfunc nb_logical_and_1; unaryfunc nb_logical_or_1; binaryfunc nb_logical_and_2; binaryfunc nb_logical_or_2; </pre></div> </div> </section> <section id="python-c-api-functions"> <h3><a class="toc-backref" href="#python-c-api-functions" role="doc-backlink">Python/C API Functions</a></h3> There are also five new Python/C API functions corresponding to the new operations: <div class="highlight-default notranslate"><div class="highlight"><pre>PyObject *PyObject_LogicalNot(PyObject *); PyObject *PyObject_LogicalAnd1(PyObject *); PyObject *PyObject_LogicalOr1(PyObject *); PyObject *PyObject_LogicalAnd2(PyObject *, PyObject *); PyObject *PyObject_LogicalOr2(PyObject *, PyObject *); </pre></div> </div> </section> </section> <section id="alternatives-and-optimisations"> <h2><a class="toc-backref" href="#alternatives-and-optimisations" role="doc-backlink">Alternatives and Optimisations</a></h2> This section discusses some possible variations on the proposal, and ways in which the bytecode sequences generated for boolean expressions could be optimised. <section id="reduced-special-method-set"> <h3><a class="toc-backref" href="#reduced-special-method-set" role="doc-backlink">Reduced special method set</a></h3> For completeness, the full version of this proposal includes a mechanism for types to define their own customised short-circuiting behaviour. However, the full mechanism is not needed to address the main use cases put forward here, and it would be possible to define a simplified version that only includes the phase 2 methods. There would then only be 5 new special methods (__and2__, __rand2__, __or2__, __ror2__, __not__) with 3 associated type slots and 3 API functions. This simplified version could be expanded to the full version later if desired. </section> <section id="additional-bytecodes"> <h3><a class="toc-backref" href="#additional-bytecodes" role="doc-backlink">Additional bytecodes</a></h3> As defined here, the bytecode sequence for code that branches on the result of a boolean expression would be slightly longer than it currently is. For example, in Python 2.7, <div class="highlight-default notranslate"><div class="highlight"><pre>if a and b: statement1 else: statement2 </pre></div> </div> generates <div class="highlight-default notranslate"><div class="highlight"><pre> LOAD_GLOBAL a POP_JUMP_IF_FALSE false_branch LOAD_GLOBAL b POP_JUMP_IF_FALSE false_branch <code for statement1> JUMP_FORWARD end_branch false_branch: <code for statement2> end_branch: </pre></div> </div> Under this proposal as described so far, it would become something like <div class="highlight-default notranslate"><div class="highlight"><pre> LOAD_GLOBAL a LOGICAL_AND_1 test LOAD_GLOBAL b LOGICAL_AND_2 test: POP_JUMP_IF_FALSE false_branch <code for statement1> JUMP_FORWARD end_branch false_branch: <code for statement2> end_branch: </pre></div> </div> This involves executing one extra bytecode in the short-circuiting case and two extra bytecodes in the non-short-circuiting case. However, by introducing extra bytecodes that combine the logical operations with testing and branching on the result, it can be reduced to the same number of bytecodes as the original: <div class="highlight-default notranslate"><div class="highlight"><pre> LOAD_GLOBAL a AND1_JUMP true_branch, false_branch LOAD_GLOBAL b AND2_JUMP_IF_FALSE false_branch true_branch: <code for statement1> JUMP_FORWARD end_branch false_branch: <code for statement2> end_branch: </pre></div> </div> Here, AND1_JUMP performs phase 1 processing as above, and then examines the result. If there is a result, it is popped from the stack, its truth value is tested and a branch taken to one of two locations. Otherwise, the first operand is left on the stack and execution continues to the next bytecode. The AND2_JUMP_IF_FALSE bytecode performs phase 2 processing, pops the result and branches if it tests false For the ‘or’ operator, there would be corresponding OR1_JUMP and OR2_JUMP_IF_TRUE bytecodes. If the simplified version without phase 1 methods is used, then early exiting can only occur if the first operand is false for ‘and’ and true for ‘or’. Consequently, the two-target AND1_JUMP and OR1_JUMP bytecodes can be replaced with AND1_JUMP_IF_FALSE and OR1_JUMP_IF_TRUE, these being ordinary branch instructions with only one target. </section> <section id="optimisation-of-not"> <h3><a class="toc-backref" href="#optimisation-of-not" role="doc-backlink">Optimisation of ‘not’</a></h3> Recent versions of Python implement a simple optimisation in which branching on a negated boolean expression is implemented by reversing the sense of the branch, saving a UNARY_NOT opcode. Taking a strict view, this optimisation should no longer be performed, because the ‘not’ operator may be overridden to produce quite different results from usual. However, in typical use cases, it is not envisaged that expressions involving customised boolean operations will be used for branching – it is much more likely that the result will be used in some other way. Therefore, it would probably do little harm to specify that the compiler is allowed to use the laws of boolean algebra to simplify any expression that appears directly in a boolean context. If this is inconvenient, the result can always be assigned to a temporary name first. This would allow the existing ‘not’ optimisation to remain, and would permit future extensions of it such as using De Morgan’s laws to extend it deeper into the expression. </section> </section> <section id="usage-examples"> <h2><a class="toc-backref" href="#usage-examples" role="doc-backlink">Usage Examples</a></h2> <section id="example-1-numpy-arrays"> <h3><a class="toc-backref" href="#example-1-numpy-arrays" role="doc-backlink">Example 1: NumPy Arrays</a></h3> <div class="highlight-default notranslate"><div class="highlight"><pre>#----------------------------------------------------------------- # # This example creates a subclass of numpy array to which # 'and', 'or' and 'not' can be applied, producing an array # of booleans. # #----------------------------------------------------------------- from numpy import array, ndarray class BArray(ndarray): def __str__(self): return "barray(%s)" % ndarray.__str__(self) def __and2__(self, other): return (self & other) def __or2__(self, other): return (self & other) def __not__(self): return (self == 0) def barray(*args, **kwds): return array(*args, **kwds).view(type = BArray) a0 = barray([0, 1, 2, 4]) a1 = barray([1, 2, 3, 4]) a2 = barray([5, 6, 3, 4]) a3 = barray([5, 1, 2, 4]) print "a0:", a0 print "a1:", a1 print "a2:", a2 print "a3:", a3 print "not a0:", not a0 print "a0 == a1 and a2 == a3:", a0 == a1 and a2 == a3 print "a0 == a1 or a2 == a3:", a0 == a1 or a2 == a3 </pre></div> </div> </section> <section id="example-1-output"> <h3><a class="toc-backref" href="#example-1-output" role="doc-backlink">Example 1 Output</a></h3> <div class="highlight-default notranslate"><div class="highlight"><pre>a0: barray([0 1 2 4]) a1: barray([1 2 3 4]) a2: barray([5 6 3 4]) a3: barray([5 1 2 4]) not a0: barray([ True False False False]) a0 == a1 and a2 == a3: barray([False False False True]) a0 == a1 or a2 == a3: barray([False False False True]) </pre></div> </div> </section> <section id="example-2-database-queries"> <h3><a class="toc-backref" href="#example-2-database-queries" role="doc-backlink">Example 2: Database Queries</a></h3> <div class="highlight-default notranslate"><div class="highlight"><pre>#----------------------------------------------------------------- # # This example demonstrates the creation of a DSL for database # queries allowing 'and' and 'or' operators to be used to # formulate the query. # #----------------------------------------------------------------- class SQLNode(object): def __and2__(self, other): return SQLBinop("and", self, other) def __rand2__(self, other): return SQLBinop("and", other, self) def __eq__(self, other): return SQLBinop("=", self, other) class Table(SQLNode): def __init__(self, name): self.__tablename__ = name def __getattr__(self, name): return SQLAttr(self, name) def __sql__(self): return self.__tablename__ class SQLBinop(SQLNode): def __init__(self, op, opnd1, opnd2): self.op = op.upper() self.opnd1 = opnd1 self.opnd2 = opnd2 def __sql__(self): return "(%s %s %s)" % (sql(self.opnd1), self.op, sql(self.opnd2)) class SQLAttr(SQLNode): def __init__(self, table, name): self.table = table self.name = name def __sql__(self): return "%s.%s" % (sql(self.table), self.name) class SQLSelect(SQLNode): def __init__(self, targets): self.targets = targets self.where_clause = None def where(self, expr): self.where_clause = expr return self def __sql__(self): result = "SELECT %s" % ", ".join([sql(target) for target in self.targets]) if self.where_clause: result = "%s WHERE %s" % (result, sql(self.where_clause)) return result def sql(expr): if isinstance(expr, SQLNode): return expr.__sql__() elif isinstance(expr, str): return "'%s'" % expr.replace("'", "''") else: return str(expr) def select(*targets): return SQLSelect(targets) #----------------------------------------------------------------- dishes = Table("dishes") customers = Table("customers") orders = Table("orders") query = select(customers.name, dishes.price, orders.amount).where( customers.cust_id == orders.cust_id and orders.dish_id == dishes.dish_id and dishes.name == "Spam, Eggs, Sausages and Spam") print repr(query) print sql(query) </pre></div> </div> </section> <section id="example-2-output"> <h3><a class="toc-backref" href="#example-2-output" role="doc-backlink">Example 2 Output</a></h3> <div class="highlight-default notranslate"><div class="highlight"><pre><__main__.SQLSelect object at 0x1cc830> SELECT customers.name, dishes.price, orders.amount WHERE (((customers.cust_id = orders.cust_id) AND (orders.dish_id = dishes.dish_id)) AND (dishes.name = 'Spam, Eggs, Sausages and Spam')) </pre></div> </div> </section> </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-0335.rst">https://github.com/python/peps/blob/main/peps/pep-0335.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0335.rst">2023-09-09 17:39:29 GMT</a> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#rejection-notice">Rejection Notice</a></li> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#background">Background</a></li> <li><a class="reference internal" href="#motivation">Motivation</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="#special-methods">Special Methods</a></li> <li><a class="reference internal" href="#bytecodes">Bytecodes</a></li> <li><a class="reference internal" href="#type-slots">Type Slots</a></li> <li><a class="reference internal" href="#python-c-api-functions">Python/C API Functions</a></li> </ul> </li> <li><a class="reference internal" href="#alternatives-and-optimisations">Alternatives and Optimisations</a><ul> <li><a class="reference internal" href="#reduced-special-method-set">Reduced special method set</a></li> <li><a class="reference internal" href="#additional-bytecodes">Additional bytecodes</a></li> <li><a class="reference internal" href="#optimisation-of-not">Optimisation of ‘not’</a></li> </ul> </li> <li><a class="reference internal" href="#usage-examples">Usage Examples</a><ul> <li><a class="reference internal" href="#example-1-numpy-arrays">Example 1: NumPy Arrays</a></li> <li><a class="reference internal" href="#example-1-output">Example 1 Output</a></li> <li><a class="reference internal" href="#example-2-database-queries">Example 2: Database Queries</a></li> <li><a class="reference internal" href="#example-2-output">Example 2 Output</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-0335.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>