Plumbing behind super()

adam.preble at gmail.com adam.preble at gmail.com
Sat Jun 29 19:15:19 EDT 2019


Thanks for the replies from everybody. It looks like I should double check super_init and see what truck is coming from that which will hit me with a gotcha later. I'm very naively right now plucking the class from my locals and I was able to proceed in the very, very short term.

I think I would have run into something like this earlier but I was doing something else incorrectly with self references in general. I was having my byte code push the object reference on the stack for method calls instead of using a naive one.

For example:
m.change_a(2)

Disregarding unrelated code, it disassembles to this in a 3.6 intepreter:
  3           6 LOAD_FAST                0 (m)
              8 LOAD_ATTR                1 (change_a)
             10 LOAD_CONST               1 (2)
             12 CALL_FUNCTION            1

I have been doing an oopsies of trying to push the self reference on the stack for the method. So I'm doing something like:
  3           6 LOAD_FAST                0 (m)
              8 LOAD_ATTR                1 (change_a)
              X LOAD_FAST                0 (m)
             10 LOAD_CONST               1 (2)
             12 CALL_FUNCTION            2

Whoops. Now I need to figure out how the interpreter knows that change_a is a method and knows what self to feed it. I'm assuming that's in the cell variables similar to what super()'s doing as explained here. I haven't implemented cell variables so this is where I'm stuck in a sand pit.



More information about the Python-list mailing list