codehaus


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] [SPAM?] Re: PEP 558: Defined semantics for locals()


On Tue, May 28, 2019 at 5:24 PM Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> Terry Reedy wrote:
> > I believe that the situation is or can be thought of as this: there is
> > exactly 1 function locals dict.  Initially, it is empty and inaccessible
> > (unusable) from code.  Each locals() call updates the dict to a current
> > snapshot and returns it.
>
> Yes, I understand *what's* happening, but not *why* it was designed
> that way.

I'm not sure of the exact history, but I think it's something like:

In the Beginning, CPython was Simple, but Slow: every frame struct had
an f_locals field, it was always a dict, the bytecode accessed the
dict, locals() returned the dict, that was that. Then one day the
serpent of Performance Optimization came, whispering of static
analysis of function scope and LOAD_FAST bytecodes. And we were
seduced by the serpent's vision, and made CPython Faster, with
semantics that were Almost The Same, and we shipped it to our users.
But now the sin of Cache Inconsistency had entered our hearts, and we
were condemned to labor endlessly: again and again, users discovered a
leak in our abstraction, and again and again we covered our sin with
new patches, until Simplicity was obscured.

(The current design does makes sense, but you really have to look at
it as a hard-fought compromise between the elegant original design
versus ~30 years of real-world demands. And hey, it could be worse ?
look at the fun Intel's been having with their caches.)

-n

--
Nathaniel J. Smith -- https://vorpus.org