From parsing a class to code object to class to mappingproxy to object (oh my!)

[adam.preble at gmail.com]

On Friday, April 5, 2019 at 5:54:42 PM UTC-5, Gregory Ewing wrote:
> But when compiling a class body, it uses a dict to hold the
> locals, and generates LOAD_NAME and STORE_NAME opcodes to
> access it.
> 
> These opcodes actually date from very early versions of
> Python, when locals were always kept in a dict. When
> optimised locals were introduced, the old mechanism was kept
> around for building class dicts. (There used to be one or
> two other uses, but I think classes are the only one left
> now.)

Thanks for the explanation. I've figured from this that I could do most variable access by just generating LOAD/STORE_NAME and the FAST is an (important) optimization. That is disregarding sneaking in the global or nolocal keywords...

So let's say I'm generating byte codes. If I am generating code for a class body, then I have a dictionary and I'm generating LOAD/STORE NAMEs. Any other body is usually going to wind up being FAST/GLOBAL/the other ones. An important exception there would be for built-ins and presumably imported stuff, right?

I'm asking because right now I've literally hard-coded some logic that tells me if I'm generating a class body so I know to use names. I just feel kind of silly doing that.