Plumbing behind super()

adam.preble at gmail.com adam.preble at gmail.com
Thu Jun 27 20:13:27 EDT 2019


I'm trying to mimick Python 3.6 as a .NET science project and have started to get into subclassing. The super() not-a-keyword-honestly-guys has tripped me up. I have to admit that I've professionally been doing a ton Python 2.7, so I'm not good on my Python 3.6 trivia yet. I think I have the general gist of this, but want some affirmation.

If you use super() in a method, all it does is load super as a global on to the interpreter stack and call it without any arguments. So I'm left to wonder how it's able to figure anything out when it's being literally given nothing...

except that it's not being given literally nothing:

static PyObject *
super_getattro(PyObject *self, PyObject *name)

I was thinking maybe self has become more special in Python 3.6, but I don't think that's true since I've ported code to Python3 before that had inner classes where I'd use "inner_self" to disambiguate with the outer self. And though I thought it was so at first, it just turned out I screwed up my little code snippet to expose it. If self was special then I presume I could find it in my lookups and inject it.

So how do I go from CALL_FUNCTION on a super() global without anything else on the stack to somehow having all the information I need? Is there something tracking that I'm in an object scope when calling stuff?




More information about the Python-list mailing list