Herencia y MRO
Python soporta herencia múltiple y resuelve métodos con el Orden de Resolución de Métodos (MRO). super() recorre ese orden, esencial para cadenas cooperativas de __init__ en mixins.
Busca en todas las páginas de la documentación
Python soporta herencia múltiple y resuelve métodos con el Orden de Resolución de Métodos (MRO). super() recorre ese orden, esencial para cadenas cooperativas de __init__ en mixins.
class LogMixin:
def log(self, msg: str) -> None:
print(f"[{self.__class__.__name__}] {msg}")
class Service(LogMixin):
def run(self) -> None:
self.log("starting")Cuándo usar esto:
class Base:
def __init__(self) -> None:
self.base_init = True
class TrackingMixin:
def __init__(self, *args, **kwargs) -> None:
self.tracked = True
super().__init__(*args, **kwargs)
class TimestampMixin:
def __init__(self, *args, **kwargs) -> None:
self.timestamped = True
super().__init__(*args, **kwargs)
class Event(TrackingMixin, TimestampMixin, Base):
pass
if __name__ == "__main__":
e = Event()
print(e.tracked, e.timestamped, e.base_init)
print(Event.mro())Lo que esto demuestra:
super().__init__ ejecutan cada clase en el MRO una vezEvent.mro() muestra el orden de resolución para depuración__init__ de los mixins se ejecutan antes de que Base complete la cadenasuper() - Salta a la siguiente clase en el MRO, no necesariamente al padre directo.super() llama a la siguiente implementación.__init__ - Cada clase en el patrón cooperativo debe llamar a super().__init__.HelpfulClass.mro() # lista de clases en orden de búsqueda
HelpfulClass.__mro__ # forma de tupla# llamada explícita de sobrescritura
class Child(Parent):
def save(self) -> None:
super().save()
self.post_save_hook()super() faltante en mixin - Rompe la cadena; algunas bases nunca se inicializan. Solución: Siempre usar super().__init__(*args, **kwargs) en mixins.__init__.super() sin bases cooperativas - Clases heredadas que no llaman a super() rompen el patrón. Solución: Adaptar o evitar la herencia múltiple.| Alternativa | Usar Cuándo | No Usar Cuándo |
|---|---|---|
| Composición | Relaciones "tiene-un" | Polimorfismo "es-un" verdadero |
| Tipado de protocolos | Interfaces estructurales | Necesidad de implementación compartida |
| Funciones + despacho | Reutilización de comportamiento simple | El patrón de método de plantilla encaja |
| Herencia simple | Jerarquía clara | Solo se necesita una capa de mixin |
El orden en que Python busca bases para atributos/métodos. Imprimir con Class.mro().
super() respeta el MRO para herencia múltiple; el padre codificado ignora los mixins cooperativos.
Pocos y pequeños están bien. Muchos mixins señalan un mal diseño; considera la composición.
Técnicamente sí; ten cuidado con la claridad de la API y las sorpresas del MRO. A menudo, la composición es más clara.
Una ABC puede estar en el MRO, exigiendo métodos antes que las clases concretas.
Llama a super().__init__ a menos que reemplaces deliberadamente toda la cadena; documenta el porqué.
El atributo de instancia oculta el método de clase; los descriptores y descriptores de datos añaden matices.
Los slots del hijo deben incluir una declaración vacía de los slots del padre; es complejo; lee la documentación antes de combinar.
Asegura Class.mro()[1] == ExpectedParent cuando el orden del mixin es crítico.
Los patrones de Django/FastAPI a menudo heredan de clases de framework; sigue la documentación del framework para las llamadas a super.
super() con métodos de claseVersiones de la pila: Esta página fue escrita para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.
Revisado por Chris St. John·Última actualización: 16 jul 2026