Plumbing behind super()
adam.preble at gmail.com
adam.preble at gmail.com
Fri Jun 28 00:10:03 EDT 2019
I was wrong in the last email because I accidentally in super_gettro instead of super_init.
Just for some helper context:
>>> class Foo:
... pass
...
>>> class Bar(Foo):
... def __init__(self):
... super().__init__()
... self.a = 2
...
>>> dis(Bar)
Disassembly of __init__:
3 0 LOAD_GLOBAL 0 (super)
2 CALL_FUNCTION 0
4 LOAD_ATTR 1 (__init__)
6 CALL_FUNCTION 0
8 POP_TOP
4 10 LOAD_CONST 1 (2)
12 LOAD_FAST 0 (self)
14 STORE_ATTR 2 (a)
16 LOAD_CONST 0 (None)
18 RETURN_VALUE
I originally set a breakpoint at super_getattro so I was seeing it getting the self pointer from TOS, but I think I needed super_init--especially since that is getting called from a CALL_FUNCTION opcode, instead of super_getattro and it's LOAD_ATTR. I think that's from the self.a assignment.
The super_init code melted my brain! It looks like it's grabbing the current frame and interrogating it to find __class__. I think I have the same amount of visibility and similar structure in what I'm writing but... woah.
More information about the Python-list
mailing list