On Mon, 4 Apr 2022 at 18:59, malmiteria <martin.milon@ensc.fr> wrote:
super(A, self) does not proxy to A, but to the first *after* A in MRO order.
Correct, that's how it's defined to work.
When you're actually in need to passing arguments to super, you very likely know what class you're gonna be targeting, and having to run MRO logic in reverse to call super to the class that comes first before your target in MRO order is what i refer to as "working around MRO".
Not at all, you pass *your own class*, and super() works things out for you. Or more simply, just omit the type and super() will work as you want it to. class A(...): def foo(): super().foo() # or super(A).foo() Note that I left the set of bases unspecified, as ..., to demonstrate that you don't need to care what they are. That's the point - the type argument to super() can be omitted in 99% of cases, and whenever it can't, it should be the last class you know about. There's no "running the MRO in reverse". In reality, I can't think of a single realistic case where you'd specify a type argument to super() anyway. Before you mention it, your xxxGoblin/HalfBreed example should be using delegation, as Steven D'Aprano pointed out - using super() in a case where you're trying to force a specific resolution path is *not what super is for*. Maybe you do have use cases where super isn't the right tool for the job. That's entirely possible. But that doesn't mean we should modify super to handle those cases as well as its current function - *especially* not if there are other solutions available in Python today, which don't use super. If you're trying to hit a nail into a piece of wood, and your screwdriver isn't doing a good job at it, that means that you should learn about hammers, not that you should propose that screwdrivers get modified to get better at hitting nails... Paul