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 280 – Optimizing access to globals | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0280/"> <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 280 – Optimizing access to globals | peps.python.org'> <meta property="og:description" content="This PEP describes yet another approach to optimizing access to module globals, providing an alternative to PEP 266 (Optimizing Global Variable/Attribute Access by Skip Montanaro) and PEP 267 (Optimized Access to Module Namespaces by Jeremy Hylton)."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0280/"> <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 describes yet another approach to optimizing access to module globals, providing an alternative to PEP 266 (Optimizing Global Variable/Attribute Access by Skip Montanaro) and PEP 267 (Optimized Access to Module Namespaces by Jeremy Hylton)."> <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 280</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 280 – Optimizing access to globals</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Guido van Rossum <guido at python.org></dd> <dt class="field-even">Status:</dt> <dd class="field-even"><abbr title="Inactive draft that may be taken up again at a later time">Deferred</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">10-Feb-2002</dd> <dt class="field-odd">Python-Version:</dt> <dd class="field-odd">2.3</dd> <dt class="field-even">Post-History:</dt> <dd class="field-even"></dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#deferral">Deferral</a></li> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#description">Description</a></li> <li><a class="reference internal" href="#additional-ideas">Additional Ideas</a></li> <li><a class="reference internal" href="#faqs">FAQs</a></li> <li><a class="reference internal" href="#graphics">Graphics</a></li> <li><a class="reference internal" href="#comparison">Comparison</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <section id="deferral"> <h2><a class="toc-backref" href="#deferral" role="doc-backlink">Deferral</a></h2> While this PEP is a nice idea, no-one has yet emerged to do the work of hashing out the differences between this PEP, <a class="pep reference internal" href="../pep-0266/" title="PEP 266 – Optimizing Global Variable/Attribute Access">PEP 266</a> and <a class="pep reference internal" href="../pep-0267/" title="PEP 267 – Optimized Access to Module Namespaces">PEP 267</a>. Hence, it is being deferred. </section> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> This PEP describes yet another approach to optimizing access to module globals, providing an alternative to <a class="pep reference internal" href="../pep-0266/" title="PEP 266 – Optimizing Global Variable/Attribute Access">PEP 266</a> (Optimizing Global Variable/Attribute Access by Skip Montanaro) and <a class="pep reference internal" href="../pep-0267/" title="PEP 267 – Optimized Access to Module Namespaces">PEP 267</a> (Optimized Access to Module Namespaces by Jeremy Hylton). The expectation is that eventually one approach will be picked and implemented; possibly multiple approaches will be prototyped first. </section> <section id="description"> <h2><a class="toc-backref" href="#description" role="doc-backlink">Description</a></h2> (Note: Jason Orendorff writes: “””I implemented this once, long ago, for Python 1.5-ish, I believe. I got it to the point where it was only 15% slower than ordinary Python, then abandoned it. ;) In my implementation, “cells” were real first-class objects, and “celldict” was a copy-and-hack version of dictionary. I forget how the rest worked.””” Reference: <a class="reference external" href="https://mail.python.org/pipermail/python-dev/2002-February/019876.html">https://mail.python.org/pipermail/python-dev/2002-February/019876.html</a>) Let a cell be a really simple Python object, containing a pointer to a Python object and a pointer to a cell. Both pointers may be <code class="docutils literal notranslate">NULL</code>. A Python implementation could be: <div class="highlight-default notranslate"><div class="highlight"><pre>class cell(object): def __init__(self): self.objptr = NULL self.cellptr = NULL </pre></div> </div> The cellptr attribute is used for chaining cells together for searching built-ins; this will be explained later. Let a celldict be a mapping from strings (the names of a module’s globals) to objects (the values of those globals), implemented using a dict of cells. A Python implementation could be: <div class="highlight-default notranslate"><div class="highlight"><pre>class celldict(object): def __init__(self): self.__dict = {} # dict of cells def getcell(self, key): c = self.__dict.get(key) if c is None: c = cell() self.__dict[key] = c return c def cellkeys(self): return self.__dict.keys() def __getitem__(self, key): c = self.__dict.get(key) if c is None: raise KeyError, key value = c.objptr if value is NULL: raise KeyError, key else: return value def __setitem__(self, key, value): c = self.__dict.get(key) if c is None: c = cell() self.__dict[key] = c c.objptr = value def __delitem__(self, key): c = self.__dict.get(key) if c is None or c.objptr is NULL: raise KeyError, key c.objptr = NULL def keys(self): return [k for k, c in self.__dict.iteritems() if c.objptr is not NULL] def items(self): return [k, c.objptr for k, c in self.__dict.iteritems() if c.objptr is not NULL] def values(self): preturn [c.objptr for c in self.__dict.itervalues() if c.objptr is not NULL] def clear(self): for c in self.__dict.values(): c.objptr = NULL # Etc. </pre></div> </div> It is possible that a cell exists corresponding to a given key, but the cell’s objptr is <code class="docutils literal notranslate">NULL</code>; let’s call such a cell empty. When the celldict is used as a mapping, it is as if empty cells don’t exist. However, once added, a cell is never deleted from a celldict, and it is possible to get at empty cells using the <code class="docutils literal notranslate">getcell()</code> method. The celldict implementation never uses the cellptr attribute of cells. We change the module implementation to use a celldict for its <code class="docutils literal notranslate">__dict__</code>. The module’s getattr, setattr and delattr operations now map to getitem, setitem and delitem on the celldict. The type of <code class="docutils literal notranslate"><module>.__dict__</code> and <code class="docutils literal notranslate">globals()</code> is probably the only backwards incompatibility. When a module is initialized, its <code class="docutils literal notranslate">__builtins__</code> is initialized from the <code class="docutils literal notranslate">__builtin__</code> module’s <code class="docutils literal notranslate">__dict__</code>, which is itself a celldict. For each cell in <code class="docutils literal notranslate">__builtins__</code>, the new module’s <code class="docutils literal notranslate">__dict__</code> adds a cell with a <code class="docutils literal notranslate">NULL</code> objptr, whose cellptr points to the corresponding cell of <code class="docutils literal notranslate">__builtins__</code>. Python pseudo-code (ignoring rexec): <div class="highlight-default notranslate"><div class="highlight"><pre>import __builtin__ class module(object): def __init__(self): self.__dict__ = d = celldict() d['__builtins__'] = bd = __builtin__.__dict__ for k in bd.cellkeys(): c = self.__dict__.getcell(k) c.cellptr = bd.getcell(k) def __getattr__(self, k): try: return self.__dict__[k] except KeyError: raise IndexError, k def __setattr__(self, k, v): self.__dict__[k] = v def __delattr__(self, k): del self.__dict__[k] </pre></div> </div> The compiler generates <code class="docutils literal notranslate">LOAD_GLOBAL_CELL </code> (and <code class="docutils literal notranslate">STORE_GLOBAL_CELL </code> etc.) opcodes for references to globals, where <code class="docutils literal notranslate"></code> is a small index with meaning only within one code object like the const index in <code class="docutils literal notranslate">LOAD_CONST</code>. The code object has a new tuple, <code class="docutils literal notranslate">co_globals</code>, giving the names of the globals referenced by the code indexed by <code class="docutils literal notranslate"></code>. No new analysis is required to be able to do this. When a function object is created from a code object and a celldict, the function object creates an array of cell pointers by asking the celldict for cells corresponding to the names in the code object’s <code class="docutils literal notranslate">co_globals</code>. If the celldict doesn’t already have a cell for a particular name, it creates and an empty one. This array of cell pointers is stored on the function object as <code class="docutils literal notranslate">func_cells</code>. When a function object is created from a regular dict instead of a celldict, <code class="docutils literal notranslate">func_cells</code> is a <code class="docutils literal notranslate">NULL</code> pointer. When the VM executes a <code class="docutils literal notranslate">LOAD_GLOBAL_CELL </code> instruction, it gets cell number <code class="docutils literal notranslate"></code> from <code class="docutils literal notranslate">func_cells</code>. It then looks in the cell’s <code class="docutils literal notranslate">PyObject</code> pointer, and if not <code class="docutils literal notranslate">NULL</code>, that’s the global value. If it is <code class="docutils literal notranslate">NULL</code>, it follows the cell’s cell pointer to the next cell, if it is not <code class="docutils literal notranslate">NULL</code>, and looks in the <code class="docutils literal notranslate">PyObject</code> pointer in that cell. If that’s also <code class="docutils literal notranslate">NULL</code>, or if there is no second cell, <code class="docutils literal notranslate">NameError</code> is raised. (It could follow the chain of cell pointers until a <code class="docutils literal notranslate">NULL</code> cell pointer is found; but I have no use for this.) Similar for <code class="docutils literal notranslate">STORE_GLOBAL_CELL </code>, except it doesn’t follow the cell pointer chain – it always stores in the first cell. There are fallbacks in the VM for the case where the function’s globals aren’t a celldict, and hence <code class="docutils literal notranslate">func_cells</code> is <code class="docutils literal notranslate">NULL</code>. In that case, the code object’s <code class="docutils literal notranslate">co_globals</code> is indexed with <code class="docutils literal notranslate"></code> to find the name of the corresponding global and this name is used to index the function’s globals dict. </section> <section id="additional-ideas"> <h2><a class="toc-backref" href="#additional-ideas" role="doc-backlink">Additional Ideas</a></h2> <ul> <li>Never make <code class="docutils literal notranslate">func_cell</code> a <code class="docutils literal notranslate">NULL</code> pointer; instead, make up an array of empty cells, so that <code class="docutils literal notranslate">LOAD_GLOBAL_CELL</code> can index <code class="docutils literal notranslate">func_cells</code> without a <code class="docutils literal notranslate">NULL</code> check.</li> <li>Make <code class="docutils literal notranslate">c.cellptr</code> equal to c when a cell is created, so that <code class="docutils literal notranslate">LOAD_GLOBAL_CELL</code> can always dereference <code class="docutils literal notranslate">c.cellptr</code> without a <code class="docutils literal notranslate">NULL</code> check.With these two additional ideas added, here’s Python pseudo-code for <code class="docutils literal notranslate">LOAD_GLOBAL_CELL</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>def LOAD_GLOBAL_CELL(self, i): # self is the frame c = self.func_cells[i] obj = c.objptr if obj is not NULL: return obj # Existing global return c.cellptr.objptr # Built-in or NULL </pre></div> </div> </li> <li>Be more aggressive: put the actual values of builtins into module dicts, not just pointers to cells containing the actual values.There are two points to this: (1) Simplify and speed access, which is the most common operation. (2) Support faithful emulation of extreme existing corner cases. WRT #2, the set of builtins in the scheme above is captured at the time a module dict is first created. Mutations to the set of builtin names following that don’t get reflected in the module dicts. Example: consider files <code class="docutils literal notranslate">main.py</code> and <code class="docutils literal notranslate">cheater.py</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>[main.py] import cheater def f(): cheater.cheat() return pachinko() print f() [cheater.py] def cheat(): import __builtin__ __builtin__.pachinko = lambda: 666 </pre></div> </div> If <code class="docutils literal notranslate">main.py</code> is run under Python 2.2 (or before), 666 is printed. But under the proposal, <code class="docutils literal notranslate">__builtin__.pachinko</code> doesn’t exist at the time main’s <code class="docutils literal notranslate">__dict__</code> is initialized. When the function object for f is created, <code class="docutils literal notranslate">main.__dict__</code> grows a pachinko cell mapping to two <code class="docutils literal notranslate">NULLs</code>. When <code class="docutils literal notranslate">cheat()</code> is called, <code class="docutils literal notranslate">__builtin__.__dict__</code> grows a pachinko cell too, but <code class="docutils literal notranslate">main.__dict__</code> doesn’t know– and will never know –about that. When f’s return stmt references pachinko, in will still find the double-NULLs in <code class="docutils literal notranslate">main.__dict__</code>’s <code class="docutils literal notranslate">pachinko</code> cell, and so raise <code class="docutils literal notranslate">NameError</code>. A similar (in cause) break in compatibility can occur if a module global foo is del’ed, but a builtin foo was created prior to that but after the module dict was first created. Then the builtin foo becomes visible in the module under 2.2 and before, but remains invisible under the proposal. Mutating builtins is extremely rare (most programs never mutate the builtins, and it’s hard to imagine a plausible use for frequent mutation of the builtins – I’ve never seen or heard of one), so it doesn’t matter how expensive mutating the builtins becomes. OTOH, referencing globals and builtins is very common. Combining those observations suggests a more aggressive caching of builtins in module globals, speeding access at the expense of making mutations of the builtins (potentially much) more expensive to keep the caches in synch. Much of the scheme above remains the same, and most of the rest is just a little different. A cell changes to: <div class="highlight-default notranslate"><div class="highlight"><pre>class cell(object): def __init__(self, obj=NULL, builtin=0): self.objptr = obj self.builtinflag = builtin </pre></div> </div> and a celldict maps strings to this version of cells. <code class="docutils literal notranslate">builtinflag</code> is true when and only when objptr contains a value obtained from the builtins; in other words, it’s true when and only when a cell is acting as a cached value. When <code class="docutils literal notranslate">builtinflag</code> is false, objptr is the value of a module global (possibly <code class="docutils literal notranslate">NULL</code>). celldict changes to: <div class="highlight-default notranslate"><div class="highlight"><pre>class celldict(object): def __init__(self, builtindict=()): self.basedict = builtindict self.__dict = d = {} for k, v in builtindict.items(): d[k] = cell(v, 1) def __getitem__(self, key): c = self.__dict.get(key) if c is None or c.objptr is NULL or c.builtinflag: raise KeyError, key return c.objptr def __setitem__(self, key, value): c = self.__dict.get(key) if c is None: c = cell() self.__dict[key] = c c.objptr = value c.builtinflag = 0 def __delitem__(self, key): c = self.__dict.get(key) if c is None or c.objptr is NULL or c.builtinflag: raise KeyError, key c.objptr = NULL # We may have unmasked a builtin. Note that because # we're checking the builtin dict for that *now*, this # still works if the builtin first came into existence # after we were constructed. Note too that del on # namespace dicts is rare, so the expense of this check # shouldn't matter. if key in self.basedict: c.objptr = self.basedict[key] assert c.objptr is not NULL # else "in" lied c.builtinflag = 1 else: # There is no builtin with the same name. assert not c.builtinflag def keys(self): return [k for k, c in self.__dict.iteritems() if c.objptr is not NULL and not c.builtinflag] def items(self): return [k, c.objptr for k, c in self.__dict.iteritems() if c.objptr is not NULL and not c.builtinflag] def values(self): preturn [c.objptr for c in self.__dict.itervalues() if c.objptr is not NULL and not c.builtinflag] def clear(self): for c in self.__dict.values(): if not c.builtinflag: c.objptr = NULL # Etc. </pre></div> </div> The speed benefit comes from simplifying <code class="docutils literal notranslate">LOAD_GLOBAL_CELL</code>, which I expect is executed more frequently than all other namespace operations combined: <div class="highlight-default notranslate"><div class="highlight"><pre>def LOAD_GLOBAL_CELL(self, i): # self is the frame c = self.func_cells[i] return c.objptr # may be NULL (also true before) </pre></div> </div> That is, accessing builtins and accessing module globals are equally fast. For module globals, a NULL-pointer test+branch is saved. For builtins, an additional pointer chase is also saved. The other part needed to make this fly is expensive, propagating mutations of builtins into the module dicts that were initialized from the builtins. This is much like, in 2.2, propagating changes in new-style base classes to their descendants: the builtins need to maintain a list of weakrefs to the modules (or module dicts) initialized from the builtin’s dict. Given a mutation to the builtin dict (adding a new key, changing the value associated with an existing key, or deleting a key), traverse the list of module dicts and make corresponding mutations to them. This is straightforward; for example, if a key is deleted from builtins, execute <code class="docutils literal notranslate">reflect_bltin_del</code> in each module: <div class="highlight-default notranslate"><div class="highlight"><pre>def reflect_bltin_del(self, key): c = self.__dict.get(key) assert c is not None # else we were already out of synch if c.builtinflag: # Put us back in synch. c.objptr = NULL c.builtinflag = 0 # Else we're shadowing the builtin, so don't care that # the builtin went away. </pre></div> </div> Note that <code class="docutils literal notranslate">c.builtinflag</code> protects from us erroneously deleting a module global of the same name. Adding a new (key, value) builtin pair is similar: <div class="highlight-default notranslate"><div class="highlight"><pre>def reflect_bltin_new(self, key, value): c = self.__dict.get(key) if c is None: # Never heard of it before: cache the builtin value. self.__dict[key] = cell(value, 1) elif c.objptr is NULL: # This used to exist in the module or the builtins, # but doesn't anymore; rehabilitate it. assert not c.builtinflag c.objptr = value c.builtinflag = 1 else: # We're shadowing it already. assert not c.builtinflag </pre></div> </div> Changing the value of an existing builtin: <div class="highlight-default notranslate"><div class="highlight"><pre>def reflect_bltin_change(self, key, newvalue): c = self.__dict.get(key) assert c is not None # else we were already out of synch if c.builtinflag: # Put us back in synch. c.objptr = newvalue # Else we're shadowing the builtin, so don't care that # the builtin changed. </pre></div> </div> </li> </ul> </section> <section id="faqs"> <h2><a class="toc-backref" href="#faqs" role="doc-backlink">FAQs</a></h2> <ul> <li>Q: Will it still be possible to:a) install new builtins in the <code class="docutils literal notranslate">__builtin__</code> namespace and have them available in all already loaded modules right away ? b) override builtins (e.g. <code class="docutils literal notranslate">open()</code>) with my own copies (e.g. to increase security) in a way that makes these new copies override the previous ones in all modules ? A: Yes, this is the whole point of this design. In the original approach, when <code class="docutils literal notranslate">LOAD_GLOBAL_CELL</code> finds a <code class="docutils literal notranslate">NULL</code> in the second cell, it should go back to see if the <code class="docutils literal notranslate">__builtins__</code> dict has been modified (the pseudo code doesn’t have this yet). Tim’s “more aggressive” alternative also takes care of this. </li> <li>Q: How does the new scheme get along with the restricted execution model?A: It is intended to support that fully. </li> <li>Q: What happens when a global is deleted?A: The module’s celldict would have a cell with a <code class="docutils literal notranslate">NULL</code> objptr for that key. This is true in both variations, but the “aggressive” variation goes on to see whether this unmasks a builtin of the same name, and if so copies its value (just a pointer-copy of the ultimate <code class="docutils literal notranslate">PyObject*</code>) into the cell’s objptr and sets the cell’s <code class="docutils literal notranslate">builtinflag</code> to true. </li> <li>Q: What would the C code for <code class="docutils literal notranslate">LOAD_GLOBAL_CELL</code> look like?A: The first version, with the first two bullets under “Additional ideas” incorporated, could look like this: <div class="highlight-default notranslate"><div class="highlight"><pre>case LOAD_GLOBAL_CELL: cell = func_cells[oparg]; x = cell->objptr; if (x == NULL) { x = cell->cellptr->objptr; if (x == NULL) { ... error recovery ... break; } } Py_INCREF(x); PUSH(x); continue; </pre></div> </div> We could even write it like this (idea courtesy of Ka-Ping Yee): <div class="highlight-default notranslate"><div class="highlight"><pre>case LOAD_GLOBAL_CELL: cell = func_cells[oparg]; x = cell->cellptr->objptr; if (x != NULL) { Py_INCREF(x); PUSH(x); continue; } ... error recovery ... break; </pre></div> </div> In modern CPU architectures, this reduces the number of branches taken for built-ins, which might be a really good thing, while any decent memory cache should realize that <code class="docutils literal notranslate">cell->cellptr</code> is the same as cell for regular globals and hence this should be very fast in that case too. For the aggressive variant: <div class="highlight-default notranslate"><div class="highlight"><pre>case LOAD_GLOBAL_CELL: cell = func_cells[oparg]; x = cell->objptr; if (x != NULL) { Py_INCREF(x); PUSH(x); continue; } ... error recovery ... break; </pre></div> </div> </li> <li>Q: What happens in the module’s top-level code where there is presumably no <code class="docutils literal notranslate">func_cells</code> array?A: We could do some code analysis and create a <code class="docutils literal notranslate">func_cells</code> array, or we could use <code class="docutils literal notranslate">LOAD_NAME</code> which should use <code class="docutils literal notranslate">PyMapping_GetItem</code> on the globals dict. </li> </ul> </section> <section id="graphics"> <h2><a class="toc-backref" href="#graphics" role="doc-backlink">Graphics</a></h2> Ka-Ping Yee supplied a drawing of the state of things after “import spam”, where <code class="docutils literal notranslate">spam.py</code> contains: <div class="highlight-default notranslate"><div class="highlight"><pre>import eggs i = -2 max = 3 def foo(n): y = abs(i) + max return eggs.ham(y + n) </pre></div> </div> The drawing is at <a class="reference external" href="http://web.lfw.org/repo/cells.gif">http://web.lfw.org/repo/cells.gif</a>; a larger version is at <a class="reference external" href="http://lfw.org/repo/cells-big.gif">http://lfw.org/repo/cells-big.gif</a>; the source is at <a class="reference external" href="http://lfw.org/repo/cells.ai">http://lfw.org/repo/cells.ai</a>. </section> <section id="comparison"> <h2><a class="toc-backref" href="#comparison" role="doc-backlink">Comparison</a></h2> XXX Here, a comparison of the three approaches could be added. </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-0280.rst">https://github.com/python/peps/blob/main/peps/pep-0280.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0280.rst">2025-02-01 08:55:40 GMT</a> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#deferral">Deferral</a></li> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#description">Description</a></li> <li><a class="reference internal" href="#additional-ideas">Additional Ideas</a></li> <li><a class="reference internal" href="#faqs">FAQs</a></li> <li><a class="reference internal" href="#graphics">Graphics</a></li> <li><a class="reference internal" href="#comparison">Comparison</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-0280.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>