Via welk dynamisch substitutiemechanisme specificeert een **Python**-niet-klasobject zijn deelnemende klassen wanneer het voorkomt in een klasse-erfgoedlijst, waardoor de berekening van de Method Resolution Order wordt beïnvloed?

Antwoord op de vraag

Geschiedenis van de vraag

Met de goedkeuring van PEP 560 in Python 3.7 vereiste het typesysteem een manier om generieke typen zoals List[int] of Generic[T] als basisclasses te gebruiken. Voorafgaand aan deze verbetering resulteerde een poging om te erven van een geparametriseerd generiek in een TypeError, omdat deze objecten geen echte klassen waren, waardoor ontwikkelaars genoodzaakt waren om complexe metaklasse-omwegen te gebruiken die het ontwerp van bibliotheken compliceerden.

Het probleem

Wanneer de interpreter een klasse-definitie verwerkt, moet hij de Method Resolution Order (MRO) berekenen met behulp van het C3-lineariseringsalgoritme. Dit algoritme vereist dat alle basen klassen zijn. De uitdaging doet zich voor wanneer een basisobject geen klasse is, maar een generieke alias; de interpreter heeft een protocol nodig om te bepalen welke echte klassen als vervanging voor deze alias moeten staan tijdens de MRO-constructie, zonder de erfgoedsemantiek te breken.

De oplossing

Python introduceerde het __mro_entries__-protocol. Wanneer de creatie van een klasse een basis met deze methode tegenkomt, roept hij base.__mro_entries__(original_bases) aan en verwacht een tuple van klassen terug. Deze klassen vervangen de originele basis in de MRO-berekening. Bijvoorbeeld, typing.Generic implementeert dit om (Generic,) terug te geven, waardoor het als een basis kan functioneren terwijl de geparametriseerde logica gescheiden blijft.

from typing import Generic, TypeVar

T = TypeVar('T')

# Generic[T] is geen klasse, maar __mro_entries__ stelt het in staat om als een te functioneren
class Container(Generic[T]):
    pass

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

Situatie uit het leven

Een frameworkteam had behoefte aan de mogelijkheid voor gebruikers om datamodellen te definiëren met behulp van geparametriseerde generieke basissen zoals Model[UserType]. Hun eerste aanpak gebruikt een op maat gemaakte metaklasse om de creatie van de klasse te onderscheppen en typeparameters te extraheren, maar dit dwong gebruikers om met metaklasseconflicten om te gaan bij het combineren van het framework met Django of SQLAlchemy-modellen.

Ze overwegen het gebruik van een klasdecorator om de klas na definitie opnieuw te schrijven, maar deze aanpak verstoorde de statische typecontrole en IDE-autocompletion omdat de transformatie plaatsvond nadat de typechecker de broncode had geanalyseerd. Een andere alternatieve aanpak omvatte __init_subclass__, maar dit kon niet de geval afhandelen waarin de basis zelf geen klasse was.

Het team implementeerde __mro_entries__ op hun generieke fabrieksobjecten. Wanneer gebruikers class UserModel(Model[UserType]) schreven, gaf de Model[UserType] instantie (Model,) terug vanuit zijn __mro_entries__-methode. Dit stelde de klasse in staat om correct van Model te erven terwijl de fabriek de specifieke typeparameter voor runtime-validatie opsloeg. De oplossing elimineerde metaklasseconflicten, behield volledige IDE-ondersteuning en handhaafde een schone erfgoedhiërarchie die voldeed aan het C3-lineariseringsalgoritme.

Wat kandidaten vaak missen

Beïnvloedt __mro_entries__ de runtime-typecontrole of het gedrag van isinstance?

Kandidaten verwarren vaak de MRO-constructie met instantietests. __mro_entries__ werkt uitsluitend tijdens de creatie van de klasse om de __mro__-tuple op te bouwen. Het heeft geen effect op isinstance() of issubclass()-controles tijdens runtime. Die operaties zijn afhankelijk van de __class__ en __bases__-attributen van bestaande klassen, niet van de dynamische substitutie die plaatsvond tijdens de fase van klasdefinitie.

Waarom geeft __mro_entries__ een tuple terug in plaats van een enkele klasse?

Het tuple-retourtype accommodateert complexe scenario's van meervoudige overerving. Hoewel het meestal een één-element tuple zoals (Generic,) teruggeeft, staat het protocol een generieke parameter toe om gelijktijdig overerving van meerdere mixins aan te geven. Python pakt deze tuple direct uit in de basenlijst voor MRO-berekening, zodat het retourneren van (A, B) effectief maakt dat de klasse van zowel A als B erft in plaats van van de originele niet-klas basis.

Welke validatie voert Python uit op de klassen die door __mro_entries__ worden teruggegeven?

De interpreter valideert strikt dat de teruggegeven klassen een geldige erfgoedstructuur vormen. Als de tuple klassen bevat die een inconsistente MRO zouden creëren—zoals het inbrengen van een diamant-erfconflict dat de beperkingen van de C3-lineariseringsregels schendt—verhoogt Python een TypeError tijdens de klascreatie. Deze validatie zorgt ervoor dat dynamische substitutie de fundamentele erfgoedconsistentie regels van de taal niet kan omzeilen.