Python's functools.singledispatch werd geïntroduceerd in PEP 443 en vrijgegeven in Python 3.4 om generieke functiecapaciteiten aan de taal toe te voegen. Geïnspireerd door soortgelijke functies in Clojure en Julia, stelt het ontwikkelaars in staat om een enkele functienaam te schrijven die zich anders gedraagt op basis van het type van het eerste argument. Dit pakt het lange patroon aan van het gebruik van isinstance()-ketens of handmatige dispatch-tabellen, die de code vervuilen en het open/gesloten principe schenden.
Zonder een gestandaardiseerd dispatchmechanisme moeten ontwikkelaars ad-hoc typecontroles binnen functies implementeren om verschillende datatypes te verwerken. Dit leidt tot strak gekoppelde code waarbij het toevoegen van ondersteuning voor een nieuw type vereist dat de oorspronkelijke functiebron wordt aangepast, wat de uitbreidbaarheid in gevaar brengt. Bovendien presenteren virtuele subklassen en abstracte basisclasses uitdagingen voor statische dispatch-tabellen omdat ze runtime MRO (Method Resolution Order) doorloop vereisen om de beste passende implementatie te bepalen.
De implementatie gebruikt een interne _registry-woordenboek dat type-objecten toewijst aan hun bijbehorende handler-functies. Wanneer de generieke functie wordt aangeroepen, haalt deze het type van het eerste argument op en voert een opzoeking uit. Als het exacte type niet wordt gevonden, doorloopt het de MRO van het type om de dichtstbijzijnde geregistreerde bovenklasse te vinden. De register()-methode fungeert als een decoratorfabriek die dit register bevolkt. Voor virtuele subklassen (deze geregistreerd met register() op abstracte basisclasses) controleert de dispatcher isinstance() tegen geregistreerde abstracte types als er geen concreet type overeenkomt, waardoor polymorfe dispatch mogelijk wordt zonder overerving.
from functools import singledispatch from abc import ABC class Shape(ABC): pass class Circle(Shape): def __init__(self, radius): self.radius = radius @singledispatch def area(obj): raise NotImplementedError("Type niet ondersteund") @area.register(Circle) def _(obj): return 3.14 * obj.radius ** 2 # Ondersteuning voor virtuele subklassen @area.register(Shape) def _(obj): return "Abstracte vorm oppervlakte"
Overweeg een gegevensverwerkingspipeline die bestanden uit verschillende bronnen binnenhaalt — JSON, XML, en CSV — die elk verschillende parserlogica vereisen maar een gestandaardiseerde interne representatie producen. De initiële implementatie gebruikte een monolithische parse_data(data, file_type)-functie met een groot if/elif/else-blok dat isinstance of stringidentificaties controleerde. Dit werd onhoudbaar naarmate er nieuwe indelingen werden toegevoegd, wat aanpassingen aan de kernfunctie vereiste en regressierisico's creëerde.
Een alternatieve oplossing was het Visitor-patroon, dat de parseralgoritmen scheidt van de datatypestructuren. Hoewel dit het open/gesloten principe afdwingt, vereist het het creëren van een parallelle hiërarchie van bezoekersklassen en accept-methoden, wat aanzienlijke boilerplate introduceert voor eenvoudige type-gebaseerde dispatch. Het patroon voelt ook onnatuurlijk aan wanneer de datatypestructuren eenvoudige strings of bytes zijn in plaats van complexe objecten.
Een andere overweging was een handmatig dispatch-woordenboek dat type-identificaties aan handler-functies toewijst. Dit ontkoppelt de registratie van de implementatie, maar mist integratie met Python's typesysteem. Het kan automatisch geen erfelijkheids hiërarchieën of abstracte basisclasses verwerken, waardoor ontwikkelaars handmatig de beste handler moesten oplossen door de MRO op elke aanroeplocatie te doorlopen, wat foutgevoelig en repetitief is.
Het team koos voor functools.singledispatch omdat het eersteklas ondersteuning biedt voor type-gebaseerde dispatch met automatische MRO-oplossing en een schone op decoratoren gebaseerde registratiesyntax. Het stelt externe bibliotheken in staat om de parserondersteuning voor nieuwe indelingen uit te breiden zonder de kernbibliotheekcode aan te passen. Het resultaat was een vermindering van 40% in het aantal regels code voor de parsingmodule en eliminatie van samensmeltconflicten bij het toevoegen van nieuwe indelinghandlers, aangezien elke indeling nu in zijn eigen onafhankelijke registratiemodule leeft.
Hoe lost singledispatch de juiste implementatie op wanneer het exacte argumenttype niet geregistreerd is, en welke rol speelt de Method Resolution Order (MRO)?
Wanneer de generieke functie een argument ontvangt waarvan het type niet expliciet in het register staat, inspecteert de dispatcher de klassehiërarchie van het argument met type(obj).__mro__. Het doorloopt de MRO-tuple — die de klasse van het object gevolgd door zijn ouders in lineariseringsvolgorde opsomt — en retourneert de eerste geregistreerde functie die aan een type in die volgorde is gekoppeld. Dit zorgt ervoor dat een handler die voor een bovenklasse is geregistreerd, correct omgaat met instanties van zijn subklassen, waarmee de Liskov Substitution Principle-naleving wordt gehandhaafd. Als er na het doorlopen van de gehele MRO geen overeenstemming wordt gevonden, valt de dispatcher terug op de oorspronkelijke functie die is geregistreerd met @singledispatch, die doorgaans NotImplementedError oproept.
Kun je een bestaande functie (geen decorator) of een lambda registreren met singledispatch, en wat is de syntaxis voor het afmelden van een type?
Ja, je kunt bestaande functies registreren met de functionele vorm: generic_func.register(target_type, existing_function). Dit is nuttig wanneer je naar een elders gedefinieerde functie of naar een lambda wilt dispatchen: process.register(int, lambda x: x * 2). Om een type af te melden, wijs je None toe aan dat type in het register: process.registry[int] = None. Dit verwijdert de specifieke handler, waardoor toekomstige dispatches voor dat type terugvallen op de MRO-zoekopdracht of de standaardimplementatie. Kandidaten missen dit vaak omdat de decoratorsyntaxis in de documentatie wordt benadrukt, terwijl de imperatieve API minder prominent is.
Hoe verschilt functools.singledispatchmethod van singledispatch wanneer het binnen een klasse wordt gebruikt, en waarom is een aparte implementatie nodig?
signedispatchmethod is vereist voor methoden omdat singledispatch werkt op het eerste argument van de functie, dat voor methoden self is. Als je singledispatch rechtstreeks op een methode zou toepassen, zou het dispatchen op basis van het type van de instantie in plaats van het type van de volgende argumenten zijn. singledispatchmethod gebruikt het descriptorprotocol om de dispatchlogica van het bindproces te scheiden: het bindt eerst self, en vervolgens past het type-dispatch toe op de overige argumenten. Dit zorgt ervoor dat het type van self geen invloed heeft op het beoogde dispatchdoel, waardoor methoden kunnen overbelasten op basis van het type van hun eerste niet-zelfargument, vergelijkbaar met hoe C++ of Java methodenoverbelasting behandelen.