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