Durch welchen dynamischen Substitutionsmechanismus gibt ein **Python**-Objekt, das keine Klasse ist, seine beteiligten Klassen an, wenn es in einer Klassenvererbungsliste erscheint, und beeinflusst somit die Berechnung der Methodenauflösungsreihenfolge?

Antwort auf die Frage

Geschichte der Frage

Mit der Annahme von PEP 560 in Python 3.7 erforderte das Typsystem eine Möglichkeit, generische Typen wie List[int] oder Generic[T] als Basisklassen zu verwenden. Vor dieser Verbesserung führte der Versuch, von einem parametrierten Generikum zu erben, zu einem TypeError, da diese Objekte keine echten Klassen waren, was die Entwickler zwang, auf komplexe Metaklassen-Workarounds zurückzugreifen, die das Design von Bibliotheken komplizierten.

Das Problem

Wenn der Interpreter eine Klassendefinition verarbeitet, muss er die Methodenauflösungsreihenfolge (MRO) mithilfe des C3-Liniierungsalgorithmus berechnen. Dieser Algorithmus erfordert, dass alle Basen Klassen sind. Das Problem tritt auf, wenn ein Basisobjekt keine Klasse, sondern ein generischer Alias ist; der Interpreter benötigt ein Protokoll, um zu bestimmen, welche echten Klassen während der Konstruktion der MRO für diesen Alias stehen sollen, ohne die Vererbungssemantik zu verletzen.

Die Lösung

Python führte das Protokoll __mro_entries__ ein. Wenn die Klassenerstellung auf eine Basis mit dieser Methode trifft, ruft sie base.__mro_entries__(original_bases) auf und erwartet eine Tuple von Klassen als Rückgabe. Diese Klassen ersetzen die ursprüngliche Basis in der MRO-Berechnung. Zum Beispiel implementiert typing.Generic dies, um (Generic,) zurückzugeben, was es ihm ermöglicht, als Basis zu fungieren, während die parametrisierte Logik getrennt bleibt.

from typing import Generic, TypeVar

T = TypeVar('T')

# Generic[T] ist keine Klasse, aber __mro_entries__ ermöglicht es, wie eine zu agieren
class Container(Generic[T]):
    pass

# Container.__mro__ enthält Generic, nicht Generic[T]
print(Container.__mro__)  # (<class 'Container'>, <class 'typing.Generic'>, <class 'object'>)

Situation aus dem Leben

Ein Framework-Team musste es den Benutzern ermöglichen, Datenmodelle mit parametrisierten generischen Basen wie Model[UserType] zu definieren. Ihr anfänglicher Ansatz verwendete eine benutzerdefinierte Metaklasse, um die Klassenerstellung abzufangen und Typparameter zu extrahieren, aber dies zwang die Benutzer dazu, Metaklassenkonflikte manuell zu beheben, wenn das Framework mit Django- oder SQLAlchemy-Modellen kombiniert wurde.

Sie überlegten, einen Klassendekorator zu verwenden, um die Klasse nach der Definition umzuschreiben, aber dieser Ansatz brach die statische Typprüfung und die IDE-Autovervollständigung, da die Transformation nach der Analyse des Quellcodes durch den Typprüfer stattfand. Eine andere Alternative umfasste __init_subclass__, konnte jedoch den Fall nicht behandeln, in dem die Basis selbst keine Klasse war.

Das Team implementierte __mro_entries__ in ihren generischen Fabrikobjekten. Wenn Benutzer class UserModel(Model[UserType]) schrieben, gab die Instanz Model[UserType] (Model,) von ihrer __mro_entries__-Methode zurück. Dies ermöglichte es der Klasse, korrekt von Model zu erben, während die Fabrik den spezifischen Typparameter für die Laufzeitvalidierung speicherte. Die Lösung beseitigte Metaklassenkonflikte, bewahrte die vollständige IDE-Unterstützung und hielt eine saubere Vererbungshierarchie bei, die den Anforderungen des C3-Liniierungsalgorithmus entsprach.

Was Bewerber oft übersehen

Beeinflusst __mro_entries__ die Laufzeit-Typprüfung oder das Verhalten von isinstance?

Bewerber verwechseln oft die MRO-Konstruktion mit der Instanzprüfung. __mro_entries__ funktioniert ausschließlich während der Klassenerstellung, um das __mro__-Tupel zu erstellen. Es hat keinen Einfluss auf isinstance() oder issubclass()-Prüfungen zur Laufzeit. Diese Operationen basieren auf den Attributen __class__ und __bases__ vorhandener Klassen, nicht auf dem dynamischen Substitutionsprozess, der während der Klassendefinitionsphase stattgefunden hat.

Warum gibt __mro_entries__ ein Tupel zurück, anstatt eine einzige Klasse?

Der Rückgabetyp Tupel ist für komplexe Szenarien mit mehrfacher Vererbung geeignet. Obwohl es häufig ein ein-elementiges Tupel wie (Generic,) zurückgibt, erlaubt das Protokoll, dass ein generischer Parameter die Vererbung von mehreren Mixins gleichzeitig impliziert. Python entpackt dieses Tupel direkt in die Basenliste zur Berechnung der MRO, sodass die Rückgabe von (A, B) die Klasse effektiv von sowohl A als auch B erben lässt, anstatt von der ursprünglichen Nicht-Klassenbasis.

Welche Validierung führt Python an den Klassen durch, die von __mro_entries__ zurückgegeben werden?

Der Interpreter validiert streng, dass die zurückgegebenen Klassen ein gültiges Vererbungsgrafen bilden. Wenn das Tupel Klassen enthält, die eine inkonsistente MRO erzeugen würden — wie etwa eine diamantene Vererbungskonflikt, die die Constraints der C3-Liniierung verletzt — wirft Python während der Klassenerstellung einen TypeError aus. Diese Validierung sorgt dafür, dass dynamische Substitution die grundlegenden Regeln der Konsistenz der Vererbung in der Sprache nicht umgehen kann.