De zero-argument super() is afhankelijk van een door de compiler gegenereerde closure cell genaamd __class__ die impliciet wordt aangemaakt voor elke methode die lexicaal binnen een Python klasse-lichaam is gedefinieerd. Wanneer de compiler een klasse-definitie verwerkt, creëert hij een cell-variabele __class__ in de closure van de methode die verwijst naar het klasse-object dat momenteel wordt gedefinieerd. Wanneer super() zonder argumenten wordt aangeroepen, inspecteert de C-implementatie het aanroepingsraam, lokaliseert deze __class__-cell en gebruikt het als het eerste argument (het type). Het gebruikt dan het eerste positionele argument van de methode (meestal self) als de instantie. Dit mechanisme bindt de klassenreferentie op het moment van definitie in plaats van op het moment van aanroep, waardoor de noodzaak om klassenamen hard te coderen wordt geëlimineerd terwijl ervoor wordt gezorgd dat elke methode in een erfelijkheidsketen naar zijn eigen specifieke positie in de MRO (Method Resolution Order) verwijst.
class Base: def method(self): return "Base" class Middle(Base): def method(self): # __class__ is hier gebonden aan Middle return f"Middle -> {super().method()}" class Derived(Middle): def method(self): # __class__ is hier gebonden aan Derived return f"Derived -> {super().method()}"
We onderhielden een kwantitatieve handelsbibliotheek met een diepe hiërarchie van prijsmodellen. Het BaseModel bood een calculate_risk() methode, EquityModel overschreef het om aandelen-specifieke logica toe te voegen, en AmericanOptionModel specialiseerde het verder. Tijdens een grote refactor om EquityModel om te dopen naar VanillaEquityModel, ontdekten we tientallen verouderde super(EquityModel, self) aanroepen in mixin-klassen die kopieer-en-plak waren. Deze verouderde referenties veroorzaakten TypeError of stille logische fouten waarbij de verkeerde bovenliggende methode werd aangeroepen, wat de risicoberekeningen in productie verstoorde.
Oplossing 1: Wereldwijde zoeken-en-vervangen refactoring. We overwoogen het gebruik van geautomatiseerde tools om alle hardcoded klassenamen in super() aanroepen door het 200.000-regel tellende codebestand te vinden en te vervangen. Voordelen: Het vereist geen architectonische wijzigingen en werkt met legacy Python 2-syntax. Nadelen: Het is kwetsbaar en incompleet; het mist dynamisch gegenereerde klassen, string-gebaseerde dynamische methode-toewijzingen en referenties in derde-partij extensies. Het schendt ook het DRY-principe, omdat de klassenaam in elke methode wordt herhaald.
Oplossing 2: Universele adoptie van zero-argument super(). We migreerden de gehele codebasis om super() zonder argumenten te gebruiken. Voordelen: Dit maakt het hernoemen van klassen volledig veilig, elimineert een belangrijke bron van menselijke fouten tijdens refactoring, en verbetert de leesbaarheid aanzienlijk door overbodig lawaai te verwijderen. Het handelt correct complexe coöperatieve meervoudige erfelijkheidspatronen af. Nadelen: Het vereist Python 3.6+ (wat we hadden), en ontwikkelaars die niet bekend waren met het impliciete closure-mechanisme vonden het aanvankelijk verwarrend. Het kan ook niet worden gebruikt in functies die dynamisch aan klassen worden gehecht na de definitie.
Oplossing 3: Metaklasse-injectie van klassenreferenties. We overwoogen kort het gebruik van een metaklasse om een _defining_class attribuut in elke methode te injecteren. Voordelen: Dit maakt het mechanisme expliciet en inspecteerbaar. Nadelen: Het voegt aanzienlijke complexiteit en overhead toe, conflicteert met standaard CPython optimalisatie, en herinventeert een functie die al door de compiler van de taal wordt aangeboden.
We kozen voor Oplossing 2. De migratie werd binnen één sprint voltooid. Het resultaat was een vermindering van 40% in de tijd die werd besteed aan vervolgrefactoringstaken die betrokken waren bij het hernoemen van klassen, en de eliminatie van een gehele klasse van bugs met betrekking tot verouderde super() referenties in onze CI-pijplijn.
Hoe lokaliseert super() fysiek de __class__ cell wanneer het met nul argumenten wordt aangeroepen?
De implementatie van super() in CPython (in Objects/typeobject.c) gebruikt PyEval_GetLocals() om de lokale variabelen en closure van het aanroepingsraam te inspecteren. Het zoekt specifiek naar een vrije variabele (cell) genaamd __class__. Deze cell wordt alleen door de compiler aangemaakt wanneer een functie lexicaal binnen een klaslichaam wordt gedefinieerd (aangegeven door de CO_OPTIMIZED vlag en de klasse-scope). Als de cell wordt gevonden, haalt super() het klasse-object op; als dat niet het geval is, wordt er een RuntimeError opgegeven: super(): class cell niet gevonden. De zero-argument vorm wordt in wezen door de compiler omgevormd in super(__class__, self), waarbij __class__ de gesloten variabele is.
Wat gebeurt er als je probeert zero-argument super() binnen een functie te gebruiken die als klasse-attribuut na de creatie van de klasse is toegewezen?
Als je een functie buiten een klasse-lichaam definieert en deze vervolgens als een methode toewijst (bijvoorbeeld, MyClass.method = some_function), zal het aanroepen van super() binnen die functie een RuntimeError veroorzaken. Dit gebeurt omdat de compiler alleen de __class__ cell aanmaakt voor code-objecten die zijn gecompileerd als onderdeel van een klasse-suite. Zonder de cell heeft super() geen manier om te bepalen welke klasse in de hiërarchie de "huidige" klasse is, omdat het niet kan onderscheiden tussen de definitie-scope van de functie en de klasse waaraan het later is gehecht.
Waarom veroorzaakt zero-argument super() geen oneindige recursie wanneer een subklasse-methode super() aanroept en de bovenliggende methode ook super() aanroept?
Dit werkt omdat __class__ verwijst naar de klasse waarin de methode is gedefinieerd, niet de runtime klasse van de instantie (type(self)). Wanneer Derived.method() super() aanroept, vindt het __class__ is Derived en delegeert het naar de volgende klasse in Derived.__mro__ (bijvoorbeeld Middle). Wanneer Middle.method() is bereikt en super() aanroept, bevat zijn eigen distincte __class__ cell Middle, zodat het de volgende klasse na Middle (bijvoorbeeld Base) opzoekt. Elk niveau van de hiërarchie gebruikt zijn eigen klassenreferentie op het moment van definitie, waardoor de MRO lineair omhoog precies één keer wordt doorlopen zonder terug te keren naar de subklasse.