Python-generatoren zijn geïmplementeerd als onderbroken frame-objecten (PyFrameObject) die hun uitvoeringsstatus tussen aanroepen behouden. Wanneer send(value) wordt aangeroepen, duwt de interne functie gen_send_ex() van CPython deze waarde op de waardestapel van de generator, die de yield-expressie vervolgens popt en teruggeeft aan de aanroeper. Dit verschilt van de initiële next()-aanroep, die impliciet None verzendt om de generator vanuit zijn oorspronkelijke staat (waar f_lasti == -1) naar de eerste yield-expressie te primen. Als send() wordt aangeroepen met een niet-None waarde voordat de generator voor de eerste keer heeft yielded, genereert CPython een TypeError omdat het generatorframe geen stapelpositie heeft om de waarde te ontvangen. Dit architecturale onderscheid zorgt ervoor dat bidirectionele communicatie pas begint nadat de generator zijn eerste opschortingspunt heeft bereikt.
We moesten een datagestuurde pijpleiding implementeren die rekening hield met backpressure voor het verwerken van hoogfrequente marktgegevensstromen, waarbij downstream consumenten dynamisch upstream producenten konden signaleren om de gegevensstroom te throttlen of te hervatten zonder berichten te verliezen of geheugen uit te putten.
Een overwogen aanpak gebruikte threading met beperkte queue.Queue-instanties tussen pijplijnfases. Hoewel dit vertrouwde blocking-semantiek en threadveiligheid bood, leed het aan ernstige GIL-beperkingen en overhead door contextwisseling, wat 15% CPU verbruikte puur voor coördinatie bij hoge doorvoer, terwijl het onvoorspelbare latentiepieken toevoegde.
Een ander alternatief betrof de migratie naar asyncio-coroutines en async/await-syntaxis. Dit zou GIL-beperkingen hebben geëlimineerd, maar vereiste een totale herschrijving van onze synchrone numerieke analysetool in een async-compatibele vorm, wat een virale refactoring zou creëren die duizenden regels zakelijke logica zou raken en compatibiliteitsproblemen met legacy C-extensies zou introduceren.
Uiteindelijk kozen we voor een generator-gebaseerde coöperatieve multitaskingbenadering met send() om "vraagcredits" upstream te verzenden. Deze oplossing vermijdde volledig de GIL-overhead, vereiste geen herschrijvingen van bibliotheken, aangezien generators in synchrone code werken, en bood expliciete controleflow door demand = (yield data_chunk)-patronen waarmee downstream consumenten de upstream-productie onmiddellijk konden pauzeren door null-waarden te verzenden.
Het resultaat was een 40% reductie in geheugengebruik in vergelijking met de queue-aanpak, latentie genormaliseerd onder de 5 milliseconden, en de codebase bleef leesbaar met expliciete yield-punten die opschorting grenzen markeerden.
Waarom genereert het aanroepen van send() met een niet-None waarde op een nieuw gemaakte generator een TypeError, en hoe handhaaft deze beperking het generatorprotocol?
Wanneer een generator voor het eerst wordt aangemaakt, is de framepointer f_lasti -1, wat aangeeft dat er nog geen bytecode is uitgevoerd. De CPython-interpreter controleert of de generator niet is gestart wanneer send() wordt aangeroepen; als de verzonden waarde niet None is, genereert het een TypeError omdat de yield-expressie nog niet is bereikt om een stapelruimte voor de waarde te bieden. Deze handhaving zorgt ervoor dat de initialisatielogica van de generator wordt voltooid voordat bidirectionele communicatie begint, waardoor de invariant wordt behouden dat waarden alleen op expliciete yield-opschortingspunten in de generator stromen.
Hoe zorgt generator.close() ervoor dat opruimcode binnen de generator wordt uitgevoerd, en wat onderscheidt de GeneratorExit-exceptie van reguliere excepties?
De close()-methode verzendt een GeneratorExit-exceptie de generator binnen op het huidige opschortingspunt door throw(GeneratorExit) aan te roepen. GeneratorExit erft van BaseException in plaats van Exception om te voorkomen dat deze wordt opgevangen door algemene except Exception-handlers die het mogelijk onjuist kunnen onderdrukken. Als de generator GeneratorExit opvangt en deze opnieuw opwekt of normaal afsluit, retourneert close() stil; als de generator echter een waarde yieldt als reactie op GeneratorExit, genereert CPython een RuntimeError omdat een sluitende generator geen nieuwe waarden mag produceren. Dit mechanisme garandeert dat finally-blokken en contextbeheerders binnen de generatorlichaam worden uitgevoerd, zelfs tijdens geforceerde beëindiging.
Welk mechanisme stelt yield from in staat om verzonden waarden transparant over geneste generators te verwerken, en hoe verschilt dit van handmatige delegatie met een lus met send()?
De yield from-syntaxis delegeert niet alleen iteratie, maar ook het volledige generatorprotocol aan een sub-generator. Wanneer de buitenste generator yield from subgen() uitvoert, transformeert CPython de send(value) van de aanroeper in een directe verzending naar de sub-generator totdat deze StopIteration opwerpt (wiens waarde het resultaat wordt van de yield from-expressie). Dit verschilt van handmatige delegatie waar een lus zoals for x in subgen(): yield x geen verzonden waarden in de buitenste generator kan onderscheppen om ze naar de innerlijke te sturen. De yield from-constructie 'vlakt' in wezen de call stack af, waardoor bidirectionele gegevensstroom door willekeurig diepe generatornesting mogelijk is zonder boilerplate doorstuurcode, terwijl het de juiste exceptie-propagatie en sluitingssemantiek behoudt.