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

[adam.preble at gmail.com]

On Thursday, April 4, 2019 at 1:17:02 PM UTC-5, adam.... at gmail.com wrote:

> Thanks for the response. I was meaning to write back earlier, but I've been spending my free Python time in the evenings reimplementing what I'm doing to work more correctly. I'm guessing before the code object representing the class body gets run, __build_class__ is establishing various dunders such as __name__, __qual_name__, and __module__. I haven't fully penetrated that, but I also took an embarrassingly long amount of time to fully comprehend LOAD_NAME versus LOAD_FAST versus LOAD_GLOBAL...

I was blabbing on this while I was away from my examples so I did botch this up a bit. I guess when building the class, __name__ will get set beforehand, it the program's setting __qualname__ and __module__ from there. Something I don't really understand from a code generation perspective is the switch over to STORE_NAME for class methods. When I disassemble regular function definitions, I expect to see the result of MAKE_FUNCTION stored using STORE_FAST. However, in the code generated from a class body, it's a STORE_NAME. I know this is signifying to the interpeter not to rely on sourcing __init__ locally, but I don't understand why it suddenly has decided that now that it's in a class body.

I'm in a situation where I am have to generate those opcodes so I'm trying to figure out what the magic switch is--if it isn't just that I'm inside a class definition now.