El super() sin argumentos se basa en una celda de cierre generada por el compilador llamada __class__ que se crea implícitamente para cualquier método definido léxicamente dentro de un cuerpo de clase de Python. Cuando el compilador procesa una definición de clase, crea una variable de celda __class__ en el cierre del método que apunta al objeto de clase que se está definiendo actualmente. Cuando se llama a super() sin argumentos, la implementación en C inspecciona el marco de llamada, localiza esta celda __class__ y la utiliza como el primer argumento (el tipo). Luego, utiliza el primer argumento posicional del método (generalmente self) como la instancia. Este mecanismo vincula la referencia de la clase en el momento de la definición en lugar del momento de la llamada, eliminando la necesidad de codificar nombres de clase mientras se asegura de que cada método en una cadena de herencia se refiera a su propia posición específica en el MRO (Orden de Resolución de Métodos).
class Base: def method(self): return "Base" class Middle(Base): def method(self): # __class__ está vinculado a Middle aquí return f"Middle -> {super().method()}" class Derived(Middle): def method(self): # __class__ está vinculado a Derived aquí return f"Derived -> {super().method()}"
Manteníamos una biblioteca de comercio cuantitativo con una jerarquía profunda de modelos de precios. El BaseModel proporcionó un método calculate_risk(), EquityModel lo sobreescribió para agregar lógica específica de acciones, y AmericanOptionModel lo especializó aún más. Durante un importante refactor para renombrar EquityModel a VanillaEquityModel, descubrimos docenas de llamadas obsoletas a super(EquityModel, self) en clases mixin que habían sido copiado y pegado. Estas referencias obsoletas causaron TypeError o errores lógicos silenciosos donde se invocaba el método padre incorrecto, rompiendo los cálculos de riesgo en producción.
Solución 1: Refactorización global de búsqueda y reemplazo. Consideramos usar herramientas automatizadas para encontrar y reemplazar todos los nombres de clase codificados en las llamadas a super() a través de la base de código de 200,000 líneas. Pros: No requiere cambios arquitectónicos y funciona con la sintaxis heredada de Python 2. Contras: Es frágil e incompleta; pierde clases generadas dinámicamente, asignaciones de métodos dinámicos basadas en cadenas y referencias en extensiones de terceros. También viola el principio DRY, ya que el nombre de clase se repite en cada método.
Solución 2: Adopción universal de super() sin argumentos. Migramos toda la base de código para usar super() sin argumentos. Pros: Esto hace que el renombrado de clases sea completamente seguro, elimina una fuente importante de error humano durante la refactorización y mejora significativamente la legibilidad al eliminar ruido redundante. Maneja correctamente patrones complejos de herencia múltiple cooperativa. Contras: Requiere Python 3.6+ (que teníamos) y los desarrolladores no familiarizados con el mecanismo de cierre implícito al principio lo encontraron confuso. También no se puede usar en funciones asignadas dinámicamente a clases después de la definición.
Solución 3: Inyección de referencias de clase mediante metaclases. Consideramos brevemente usar una metaclase para inyectar un atributo _defining_class en cada método. Pros: Esto hace que el mecanismo sea explícito e inspecionable. Contras: Añade una complejidad y sobrecarga significativas, entra en conflicto con la optimización estándar de CPython y reinventa una característica que ya proporciona el compilador del lenguaje.
Elegimos Solución 2. La migración se completó en un sprint. El resultado fue una reducción del 40% en el tiempo dedicado a tareas posteriores de refactorización que involucraban el renombrado de clases, y la eliminación de toda una clase de errores relacionados con referencias obsoletas a super() en nuestra tubería de CI.
¿Cómo localiza físicamente super() la celda __class__ cuando se llama sin argumentos?
La implementación de super() en CPython (en Objects/typeobject.c) utiliza PyEval_GetLocals() para inspeccionar las variables locales y el cierre del marco de llamada. Busca específicamente una variable libre (celda) llamada __class__. Esta celda solo se crea por el compilador cuando una función se define léxicamente dentro de un cuerpo de clase (indicado por la bandera CO_OPTIMIZED y el ámbito de la clase). Si se encuentra la celda, super() extrae el objeto de clase; si no, genera un RuntimeError: super(): celda __class__ no encontrada. La forma sin argumentos es esencialmente transformada por el compilador en super(__class__, self), donde __class__ es la variable cerrada.
¿Qué sucede si intentas usar super() sin argumentos dentro de una función que se asigna a un atributo de clase después de que la clase ha sido creada?
Si defines una función fuera de un cuerpo de clase y luego la asignas como un método (por ejemplo, MyClass.method = some_function), llamar a super() dentro de esa función generará un RuntimeError. Esto ocurre porque el compilador solo crea la celda __class__ para objetos de código compilados como parte de un conjunto de clase. Sin la celda, super() no tiene forma de determinar qué clase en la jerarquía es la "clase actual", ya que no puede distinguir entre el ámbito de definición de la función y la clase a la que se adjuntó posteriormente.
¿Por qué super() sin argumentos no causa recursión infinita cuando un método de subclase llama a super() y el método padre también llama a super()?
Esto funciona porque __class__ se refiere a la clase donde se define el método, no a la clase en tiempo de ejecución de la instancia (type(self)). Cuando Derived.method() llama a super(), encuentra que __class__ es Derived y delega al siguiente clase en Derived.__mro__ (por ejemplo, Middle). Cuando se alcanza Middle.method() y llama a super(), su propia celda __class__ distinta contiene Middle, por lo que busca la siguiente clase después de Middle (por ejemplo, Base). Cada nivel de la jerarquía utiliza su propia referencia de clase en el momento de la definición, asegurando que el MRO se recorra linealmente hacia arriba exactamente una vez sin volver a la subclase.