Python-Generatoren werden als pausierte Rahmenobjekte (PyFrameObject) implementiert, die ihren Ausführungszustand zwischen den Aufrufen beibehalten. Wenn send(value) aufgerufen wird, schiebt die interne Funktion gen_send_ex() von CPython diesen Wert auf den Wertstapel des Generators, den der yield-Ausdruck dann abruft und an den Aufrufer zurückgibt. Dies unterscheidet sich vom initialen Aufruf von next(), der implizit None sendet, um den Generator von seinem anfänglichen Zustand (wo f_lasti == -1) zum ersten yield-Ausdruck zu aktivieren. Wenn send() mit einem Nicht-None-Wert aufgerufen wird, bevor der Generator zum ersten Mal einen Wert zurückgegeben hat, löst CPython einen TypeError aus, da der Generatorsrahmen keine Stapelposition hat, um den Wert zu empfangen. Diese architektonische Unterscheidung stellt sicher, dass die bidirektionale Kommunikation erst beginnt, nachdem der Generator seinen ersten Unterbrechungspunkt erreicht hat.
Wir mussten eine Datenpipeline mit Druckbewusstsein implementieren, um Hochfrequenz-Marktdatenströme zu verarbeiten, bei denen nachgelagerte Verbraucher die upstream-Produzenten dynamisch signalisieren konnten, den Datenfluss zu drosseln oder wieder aufzunehmen, ohne Nachrichten zu verlieren oder den Speicher zu erschöpfen.
Ein erwogener Ansatz verwendete Threading mit begrenzten queue.Queue-Instanzen zwischen den Pipeline-Stufen. Während dies vertraute blockierende Semantiken und Thread-Sicherheit bot, litt es unter schwerwiegender GIL-Konkurrenz und Kontextwechsel-Overhead, der 15% CPU nur für die Koordination bei hoher Durchsatzrate verbrauchte und unvorhersehbare Latenzspitzen hinzufügte.
Eine andere Alternative bestand darin, zu asyncio-Koroutinen und async/await-Syntax zu migrieren. Dies hätte die GIL-Konkurrenz eliminiert, erforderte jedoch eine vollständige Neuschreibung unserer synchronen numerischen Analysebibliothek in eine async-kompatible Form, was zu einer viralen Umstrukturierung führte, die Tausende von Codezeilen der Geschäftslogik berühren und Kompatibilitätsprobleme mit älteren C-Erweiterungen einführen würde.
Wir wählten letztendlich einen generatorbasierten kooperativen Multitasking-Ansatz unter Verwendung von send(), um "Nachfragekredite" nach oben zu übertragen. Diese Lösung vermied die GIL-Überlastung vollständig, erforderte keine Bibliotheksneuschreibungen, da Generatoren in synchronem Code funktionieren, und bot explizite Steuerflüsse durch demand = (yield data_chunk)-Muster, die es den nachgelagerten Verbrauchern ermöglichten, die Produktion von oben sofort zu pausieren, indem sie Nullwerte sendeten.
Das Ergebnis war eine 40%ige Reduzierung des Speicherverbrauchs im Vergleich zum Queue-Ansatz, die Latenz stabilisierte sich unter 5 Millisekunden, und der Code blieb lesbar, mit expliziten Yield-Punkten, die die Unterbrechungsgrenzen markierten.
Warum führt das Aufrufen von send() mit einem Nicht-None-Wert auf einem neu erstellten Generator zu einem TypeError und wie erzwingt diese Einschränkung das Generatorprotokoll?
Wenn ein Generator zum ersten Mal erstellt wird, ist sein Rahmenzeiger f_lasti -1, was anzeigt, dass kein Bytecode ausgeführt wurde. Der CPython-Interpreter prüft, ob der Generator uninitialized ist, wenn send() aufgerufen wird; wenn der gesendete Wert nicht None ist, löst er einen TypeError aus, da der yield-Ausdruck noch nicht erreicht wurde, um einen Stapelplatz für den Wert bereitzustellen. Diese Durchsetzung stellt sicher, dass die Initialisierungslogik des Generators vollständig abgeschlossen wird, bevor die bidirektionale Kommunikation beginnt, und hält die Invarianz aufrecht, dass Werte nur an expliziten yield-Unterbrechungspunkten in den Generator fließen.
Wie stellt generator.close() sicher, dass der Bereinigungscode innerhalb des Generators ausgeführt wird, und was unterscheidet die GeneratorExit-Ausnahme von regulären Ausnahmen?
Die Methode close() sendet eine GeneratorExit-Ausnahme in den Generator an seinem aktuellen Unterbrechungspunkt, indem sie throw(GeneratorExit) aufruft. GeneratorExit erbt von BaseException anstelle von Exception, um zu verhindern, dass sie von generischen except Exception-Handlern abgefangen wird, die sie möglicherweise fälschlicherweise behandeln. Wenn der Generator GeneratorExit abfängt und erneut auslöst oder normal beendet wird, gibt close() stillschweigend zurück; jedoch, wenn der Generator als Antwort auf GeneratorExit einen Wert yieldet, löst CPython einen RuntimeError aus, da ein schließender Generator keine neuen Werte produzieren darf. Dieser Mechanismus gewährleistet, dass finally-Blöcke und Kontextmanager innerhalb des Körpers des Generators auch bei einer erzwungenen Beendigung ausgeführt werden.
Welcher Mechanismus ermöglicht es yield from, gesendete Werte transparent über genestete Generatoren zu handhaben, und wie unterscheidet sich dies von einer manuellen Delegation mit einer Schleife und send()?
Die Syntax yield from delegiert nicht nur die Iteration, sondern das vollständige Generatorprotokoll an einen Untergenerator. Wenn der äußere Generator yield from subgen() ausführt, wandelt CPython das send(value) des Aufrufers in ein direktes Senden an den Untergenerator um, bis dieser StopIteration auslöst (dessen Wert wird zum Resultat des yield from-Ausdrucks). Dies unterscheidet sich von der manuellen Delegation, bei der eine Schleife wie for x in subgen(): yield x weder die an den äußeren Generator gesendeten Werte abfangen noch sie an den inneren weiterleiten kann. Der yield from-Konstruktion flacht im Wesentlichen den Aufrufstapel ab und ermöglicht einen bidirektionalen Datenfluss durch beliebig tiefes Generatoren-Nesting, ohne sich wiederholenden Weitergabecode, während sie die richtige Ausnahmepropagation und Schließsemantik beibehält.