A través de qué mecanismo de sustitución dinámica especifica un objeto no clasificado de **Python** sus clases participantes al aparecer en una lista de herencia de clases, influyendo así en el cálculo del Orden de Resolución de Métodos?

Respuesta a la pregunta

Historia de la pregunta

Con la adopción de PEP 560 en Python 3.7, el sistema de tipos requería una manera de usar tipos genéricos como List[int] o Generic[T] como clases base. Antes de esta mejora, intentar heredar de un genérico parametrizado resultaba en un TypeError porque estos objetos no eran clases reales, obligando a los desarrolladores a recurrir a complejas soluciones de metaclases que complicaban el diseño de bibliotecas.

El problema

Cuando el intérprete procesa una definición de clase, debe calcular el Orden de Resolución de Métodos (MRO) utilizando el algoritmo de linearización C3. Este algoritmo requiere que todas las bases sean clases. El desafío surge cuando un objeto base no es una clase, sino un alias genérico; el intérprete necesita un protocolo para determinar qué clases reales deben reemplazar este alias durante la construcción del MRO sin romper la semántica de herencia.

La solución

Python introdujo el protocolo __mro_entries__. Cuando la creación de una clase encuentra una base con este método, llama a base.__mro_entries__(original_bases) y espera un tuple de clases a cambio. Estas clases reemplazan la base original en el cálculo del MRO. Por ejemplo, typing.Generic implementa esto para devolver (Generic,), permitiendo que funcione como una base mientras la lógica parametrizada permanece separada.

from typing import Generic, TypeVar

T = TypeVar('T')

# Generic[T] no es una clase, pero __mro_entries__ permite que actúe como tal
class Container(Generic[T]):
    pass

# Container.__mro__ incluye Generic, no Generic[T]
print(Container.__mro__)  # (<class 'Container'>, <class 'typing.Generic'>, <class 'object'>)

Situación de la vida real

Un equipo de framework necesitaba permitir a los usuarios definir modelos de datos utilizando bases genéricas parametrizadas como Model[UserType]. Su enfoque inicial utilizó una metaclase personalizada para interceptar la creación de la clase y extraer parámetros de tipo, pero esto obligó a los usuarios a resolver manualmente conflictos de metaclases al combinar el framework con modelos de Django o SQLAlchemy.

Consideraron usar un decorador de clase para reescribir la clase después de la definición, pero este enfoque rompió la verificación de tipos estáticos y la autocompletación de IDE porque la transformación ocurrió después de que el verificador de tipos analizara el código fuente. Otra alternativa involucraba __init_subclass__, pero esto no podía manejar el caso en que la base misma no era una clase.

El equipo implementó __mro_entries__ en sus objetos de fábrica genéricos. Cuando los usuarios escribieron class UserModel(Model[UserType]), la instancia de Model[UserType] devolvió (Model,) desde su método __mro_entries__. Esto permitió que la clase heredara correctamente de Model mientras la fábrica almacenaba el parámetro de tipo específico para la validación en tiempo de ejecución. La solución eliminó conflictos de metaclases, preservó el soporte completo de IDE y mantuvo una jerarquía de herencia limpia que satisfacía el algoritmo de linearización C3.

Lo que a menudo los candidatos pasan por alto

¿Afecta __mro_entries__ la verificación de tipos en tiempo de ejecución o el comportamiento de isinstance?

Los candidatos suelen confundir la construcción de MRO con la comprobación de instancias. __mro_entries__ opera exclusivamente durante la creación de la clase para construir el tuple __mro__. No tiene efecto en las comprobaciones de isinstance() o issubclass() en tiempo de ejecución. Estas operaciones dependen de los atributos __class__ y __bases__ de las clases existentes, no de la sustitución dinámica que ocurrió durante la fase de definición de la clase.

¿Por qué __mro_entries__ devuelve un tuple en lugar de una única clase?

El tipo de retorno de tuple acomoda escenarios complejos de herencia múltiple. Aunque comúnmente devuelve un tuple de un solo elemento como (Generic,), el protocolo permite que un parámetro genérico implique la herencia de múltiples mixins simultáneamente. Python descompone este tuple directamente en la lista de bases para el cálculo del MRO, por lo que devolver (A, B) efectivamente hace que la clase herede de tanto A como B en lugar de la base original no clase.

¿Qué validación realiza Python sobre las clases devueltas por __mro_entries__?

El intérprete valida estrictamente que las clases devueltas formen un grafo de herencia válido. Si el tuple contiene clases que crearían un MRO inconsistente—como introducir un conflicto de herencia en diamante que viola las restricciones de linearización C3—Python genera un TypeError durante la creación de la clase. Esta validación asegura que la sustitución dinámica no puede eludir las reglas fundamentales de consistencia de herencia del lenguaje.