From parsing a class to code object to class to mappingproxy to object (oh my!)
adam.preble at gmail.com wrote:
> Something I
> don't really understand from a code generation perspective is the switch over
> to STORE_NAME for class methods.
That's because, in this particular situation, the locals are
being kept in a dict instead of an array.
When compiling an ordinary function, the compiler figures out
what locals there are, and generates LOAD_FAST and STORE_FAST
opcodes to access them by index.
But when compiling a class body, it uses a dict to hold the
locals, and generates LOAD_NAME and STORE_NAME opcodes to
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