CPython’s bug tracker’s issue 805304, “super instances don’t support item assignment”, has Raymond Hettinger give a detailed explanation of perceived difficulties.
The reason this doesn’t work automatically is that such methods have to be defined on the class due to Python’s caching of methods, whilst the proxied methods are found at runtime.
He offers a patch that would give a subset of this functionality:
+ if (o->ob_type == &PySuper_Type) {
+ PyObject *result;
+ result = PyObject_CallMethod(o, "__setitem__", "(OO)", key, value);
+ if (result == NULL)
+ return -1;
+ Py_DECREF(result);
+ return 0;
+ }
+
so it is clearly possible.
However, he concludes
I’ve been thinking that this one could be left alone and just
document that super objects only do their magic upon
explicit attribute lookup.Otherwise, fixing it completely involves combing Python for
every place that directly calls functions from the slots table,
and then adding a followup call using attribute lookup if the
slot is empty.When it comes to functions like repr(obj), I think we want
the super object to identify itself rather than forwarding the
call to the target object’s __repr__() method.
The argument seems to be that if __dunder__ methods are proxied, then either __repr__ is proxied or there is an inconsistency between them. super(), thus, might not want to proxy such methods lest it gets too near the programmer’s equivalent of an uncanny valley.