Le super() sans argument repose sur une cellule de fermeture générée par le compilateur, nommée __class__, qui est implicitement créée pour toute méthode définie lexicalement dans le corps d'une classe Python. Lorsque le compilateur traite une définition de classe, il crée une variable de cellule __class__ dans la fermeture de la méthode qui pointe vers l'objet classe actuellement en cours de définition. Lorsque super() est appelé sans arguments, l'implémentation C inspecte le cadre d'appel, localise cette cellule __class__, et l'utilise comme le premier argument (le type). Elle utilise ensuite le premier argument positionnel de la méthode (généralement self) comme l'instance. Ce mécanisme associe la référence de la classe au moment de la définition plutôt qu'au moment de l'appel, éliminant la nécessité de coder en dur les noms de classe tout en s'assurant que chaque méthode dans une chaîne d'héritage fait référence à sa propre position spécifique dans le MRO (Ordre de Résolution des Méthodes).
class Base: def method(self): return "Base" class Middle(Base): def method(self): # __class__ est lié à Middle ici return f"Middle -> {super().method()}" class Derived(Middle): def method(self): # __class__ est lié à Derived ici return f"Derived -> {super().method()}"
Nous avons maintenu une bibliothèque de trading quantitatif avec une hiérarchie profonde de modèles de prix. Le BaseModel fournissait une méthode calculate_risk(), le EquityModel l'a remplacée pour ajouter une logique spécifique aux actions, et le AmericanOptionModel l'a encore spécialisée. Lors d'une refonte majeure pour renommer EquityModel en VanillaEquityModel, nous avons découvert des dizaines d'appels super(EquityModel, self) obsolètes dans des classes mixins qui avaient été copiées-collées. Ces références obsolètes ont causé des TypeError ou des erreurs logiques silencieuses où la mauvaise méthode parente était invoquée, rompant les calculs de risque en production.
Solution 1 : Refactorisation globale de recherche et remplacement. Nous avons envisagé d'utiliser des outils automatisés pour trouver et remplacer tous les noms de classe codés en dur dans les appels super() à travers la base de code de 200 000 lignes. Avantages : Cela ne nécessite aucun changement architectural et fonctionne avec la syntaxe Python 2 héritée. Inconvénients : C'est fragile et incomplet ; il manque des classes générées dynamiquement, des assignations de méthodes dynamiques basées sur des chaînes, et des références dans des extensions tierces. Cela viole également le principe DRY, car le nom de la classe est répété dans chaque méthode.
Solution 2 : Adoption universelle de super() sans argument. Nous avons migré l'ensemble de la base de code pour utiliser super() sans arguments. Avantages : Cela rend le renommage de classe complètement sûr, élimine une source majeure d'erreur humaine lors des refontes, et améliore considérablement la lisibilité en supprimant le bruit redondant. Cela gère correctement des modèles d'héritage multiple coopératifs complexes. Inconvénients : Cela nécessite Python 3.6+ (ce que nous avions), et les développeurs peu familiers avec le mécanisme de fermeture implicite l'ont initialement trouvé déroutant. Cela ne peut également pas être utilisé dans des fonctions attachées dynamiquement aux classes après la définition.
Solution 3 : Injection de références de classe par métaclasse. Nous avons brièvement envisagé d'utiliser une métaclasse pour injecter un attribut _defining_class dans chaque méthode. Avantages : Cela rend le mécanisme explicite et inspectable. Inconvénients : Cela ajoute une complexité et un overhead significatifs, entre en conflit avec l'optimisation standard de CPython, et réinvente une fonction déjà fournie par le compilateur du langage.
Nous avons choisi la Solution 2. La migration a été complétée en un sprint. Le résultat a été une réduction de 40 % du temps consacré aux tâches de refonte ultérieures impliquant le renommage de classes, et l'élimination d'une classe entière de bogues liés aux références obsolètes de super() dans notre pipeline CI.
Comment super() localise physiquement la cellule __class__ lorsqu'elle est appelée sans arguments ?
L'implémentation de super() dans CPython (dans Objects/typeobject.c) utilise PyEval_GetLocals() pour inspecter les variables locales et la fermeture du cadre d'appel. Elle recherche spécifiquement une variable libre (cellule) nommée __class__. Cette cellule est uniquement créée par le compilateur lorsqu'une fonction est définie lexicalement à l'intérieur d'un corps de classe (indiqué par le flag CO_OPTIMIZED et la portée de la classe). Si la cellule est trouvée, super() extrait l'objet classe ; sinon, elle soulève RuntimeError : super() : cellule __class__ introuvable. La forme sans argument est essentiellement transformée par le compilateur en super(__class__, self), où __class__ est la variable entourée.
Que se passe-t-il si vous essayez d'utiliser super() sans argument à l'intérieur d'une fonction qui est assignée à un attribut de classe après la création de la classe ?
Si vous définissez une fonction en dehors d'un corps de classe et que vous l'assignez ensuite comme méthode (par exemple, MyClass.method = some_function), appeler super() à l'intérieur de cette fonction soulèvera une RuntimeError. Cela se produit parce que le compilateur ne crée la cellule __class__ que pour les objets de code compilés en partie d'un ensemble de classes. Sans la cellule, super() n'a aucun moyen de déterminer quelle classe dans la hiérarchie est la "classe actuelle", car elle ne peut pas faire la distinction entre la portée de définition de la fonction et la classe à laquelle elle a été attachée plus tard.
Pourquoi super() sans argument ne provoque-t-il pas de récursion infinie lorsque la méthode d'une sous-classe appelle super() et que la méthode parente appelle également super() ?
Cela fonctionne parce que __class__ fait référence à la classe où la méthode est définie, pas la classe d'exécution de l'instance (type(self)). Lorsque Derived.method() appelle super(), il trouve que __class__ est Derived et délègue à la classe suivante dans Derived.__mro__ (par exemple, Middle). Lorsque Middle.method() est atteint et qu'il appelle super(), sa propre cellule __class__ distincte contient Middle, donc il recherche la classe suivante après Middle (par exemple, Base). Chaque niveau de la hiérarchie utilise sa propre référence de classe au moment de la définition, garantissant que le MRO est parcouru linéairement vers le haut exactement une fois sans revenir à la sous-classe.