Einleitung

Dieses PEP schlägt einige Verbesserungen an der API und Syntax von Generatoren vor, um sie als einfache Coroutinen nutzbar zu machen. Es ist im Grunde eine Kombination von Ideen aus diesen beiden PEPs, die als redundant betrachtet werden können, wenn dieses PEP angenommen wird.

• PEP 288, Generatorenattribute und Ausnahmen. Das aktuelle PEP deckt die zweite Hälfte ab, Generator-Ausnahmen (tatsächlich wurde der Methodenname throw() aus PEP 288 übernommen). PEP 342 ersetzt jedoch Generator-Attribute durch ein Konzept aus einer früheren Überarbeitung von PEP 288, den *Yield-Ausdruck*.
• PEP 325, Unterstützung für Ressourcenfreigabe für Generatoren. PEP 342 schließt einige lose Enden in der PEP 325-Spezifikation ab, um sie für die tatsächliche Implementierung geeignet zu machen.

Motivation

Coroutinen sind eine natürliche Art, viele Algorithmen auszudrücken, wie Simulationen, Spiele, asynchrone I/O und andere Formen ereignisgesteuerter Programmierung oder kooperativer Multitasking. Pythons Generatorfunktionen sind fast Coroutinen – aber eben nicht ganz –, da sie die Ausführung pausieren lassen, um einen Wert zu erzeugen, aber keine Werte oder Ausnahmen bereitstellen, die bei Wiederaufnahme der Ausführung übergeben werden können. Sie erlauben auch keine Ausführungspausen innerhalb des try-Teils von try/finally-Blöcken und machen es daher schwierig für eine abgebrochene Coroutine, sich selbst zu bereinigen.

Außerdem können Generatoren die Kontrolle nicht abgeben, während andere Funktionen ausgeführt werden, es sei denn, diese Funktionen sind selbst als Generatoren ausgedrückt und der äußere Generator ist so geschrieben, dass er als Reaktion auf von den inneren Generatoren erzeugte Werte liefert. Dies erschwert die Implementierung selbst relativ einfacher Anwendungsfälle wie asynchroner Kommunikation, da das Aufrufen von Funktionen entweder erfordert, dass der Generator *blockiert* (d. h. keine Kontrolle abgeben kann) oder es muss viel Boilerplate-Schleifencode um jeden benötigten Funktionsaufruf herum hinzugefügt werden.

Wenn es jedoch möglich wäre, Werte oder Ausnahmen *in* einen Generator an der Stelle zu übergeben, an der er angehalten wurde, könnte ein einfacher Coroutinen-Scheduler oder eine *Trampolin-Funktion* Coroutinen erlauben, sich gegenseitig aufzurufen, ohne zu blockieren – ein enormer Vorteil für asynchrone Anwendungen. Solche Anwendungen könnten dann Coroutinen schreiben, um nicht-blockierende Socket-I/O durch Abgabe der Kontrolle an einen I/O-Scheduler durchzuführen, bis Daten gesendet wurden oder verfügbar sind. In der Zwischenzeit würde der Code, der die I/O durchführt, einfach so etwas tun:

data = (yield nonblocking_read(my_socket, nbytes))

um die Ausführung zu pausieren, bis die nonblocking_read()-Coroutine einen Wert erzeugt hat.

Mit anderen Worten, mit einigen relativ geringfügigen Erweiterungen der Sprache und der Implementierung des Generator-Iterator-Typs wird Python in der Lage sein, asynchrone Operationen durchzuführen, ohne die gesamte Anwendung als Reihe von Callbacks schreiben zu müssen und ohne die Verwendung von ressourcenintensiven Threads für Programme zu benötigen, die Hunderte oder sogar Tausende von kooperativ multitaskingfähigen Pseudothreads benötigen. Somit werden diese Erweiterungen dem Standard-Python viele der Vorteile des Stackless Python-Forks bieten, ohne wesentliche Änderungen am CPython-Kern oder seinen APIs zu erfordern. Darüber hinaus sollten diese Erweiterungen von jeder Python-Implementierung (wie Jython), die bereits Generatoren unterstützt, leicht implementierbar sein.

Zusammenfassung der Spezifikation

Durch Hinzufügen einiger einfacher Methoden zum Generator-Iterator-Typ und mit zwei geringfügigen Syntaxanpassungen werden Python-Entwickler in der Lage sein, Generatorfunktionen zur Implementierung von Coroutinen und anderen Formen kooperativer Multitasking zu verwenden. Diese Methoden und Anpassungen sind:

1. Definieren Sie yield als Ausdruck statt als Anweisung neu. Die aktuelle yield-Anweisung würde zu einem yield-Ausdruck, dessen Wert verworfen wird. Der Wert eines yield-Ausdrucks ist None, wenn der Generator durch einen normalen next()-Aufruf wieder aufgenommen wird.
2. Fügen Sie eine neue send()-Methode für Generator-Iteratoren hinzu, die den Generator wieder aufnimmt und einen Wert *sendet*, der zum Ergebnis des aktuellen Yield-Ausdrucks wird. Die send()-Methode gibt den nächsten vom Generator gelieferten Wert zurück oder löst StopIteration aus, wenn der Generator ohne Lieferung eines weiteren Wertes beendet wird.
3. Fügen Sie eine neue throw()-Methode für Generator-Iteratoren hinzu, die eine Ausnahme an der Stelle auslöst, an der der Generator angehalten wurde, und die den nächsten vom Generator gelieferten Wert zurückgibt, wobei StopIteration ausgelöst wird, wenn der Generator ohne Lieferung eines weiteren Wertes beendet wird. (Wenn der Generator die übergebene Ausnahme nicht abfängt oder eine andere Ausnahme auslöst, breitet sich diese Ausnahme auf den Aufrufer aus.)
4. Fügen Sie eine close()-Methode für Generator-Iteratoren hinzu, die GeneratorExit an der Stelle auslöst, an der der Generator angehalten wurde. Wenn der Generator dann StopIteration (durch normale Beendigung oder weil er bereits geschlossen ist) oder GeneratorExit (durch Nicht-Abfangen der Ausnahme) auslöst, gibt close() an seinen Aufrufer zurück. Wenn der Generator einen Wert liefert, wird ein RuntimeError ausgelöst. Wenn der Generator eine andere Ausnahme auslöst, wird diese auf den Aufrufer übertragen. close() tut nichts, wenn der Generator bereits aufgrund einer Ausnahme oder normalen Beendigung beendet wurde.
5. Stellen Sie die Unterstützung sicher, dass close() aufgerufen wird, wenn ein Generator-Iterator durch die Müllabfuhr gesammelt wird.
6. Erlauben Sie yield in try/finally-Blöcken, da die Müllabfuhr oder ein expliziter close()-Aufruf nun dazu führen würde, dass die finally-Klausel ausgeführt wird.

Ein Prototyp-Patch, der all diese Änderungen am aktuellen Python CVS HEAD implementiert, ist als SourceForge-Patch #1223381 verfügbar (https://bugs.python.org/issue1223381).

Spezifikation: Senden von Werten in Generatoren

x = yield 42
x = yield
x = 12 + (yield 42)
x = 12 + (yield)
foo(yield 42)
foo(yield)

x = 12 + yield 42
x = 12 + yield
foo(yield 42, 12)
foo(yield, 12)

Spezifikation: Ausnahmen und Bereinigung

Sei ein Generatorobjekt der Iterator, der durch Aufrufen einer Generatorfunktion erzeugt wird. Im Folgenden bezieht sich *g* immer auf ein Generatorobjekt.

raise type, value, traceback

def close(self):
    try:
        self.throw(GeneratorExit)
    except (GeneratorExit, StopIteration):
        pass
    else:
        raise RuntimeError("generator ignored GeneratorExit")
    # Other exceptions are not caught

Optionale Erweiterungen

Offene Fragen

Diskussionen auf python-dev haben einige offene Punkte aufgedeckt. Ich liste sie hier mit meiner bevorzugten Auflösung und ihrer Begründung auf. Das PEP in seiner jetzigen Form spiegelt diese bevorzugte Auflösung wider.

1. Welche Ausnahme sollte von close() ausgelöst werden, wenn der Generator als Reaktion auf die Ausnahme GeneratorExit einen weiteren Wert liefert?

   Ich habe ursprünglich TypeError gewählt, weil sie grobes Fehlverhalten der Generatorfunktion darstellt, das durch Änderung des Codes behoben werden sollte. Aber die Dekorator-Klasse with_template in PEP 343 verwendet RuntimeError für ähnliche Vergehen. Arguably sollten sie alle dieselbe Ausnahme verwenden. Ich möchte keine neue Ausnahmeklasse nur für diesen Zweck einführen, da es keine Ausnahme ist, die ich Leute abfangen lassen möchte: Ich möchte, dass sie zu einem Traceback wird, der vom Programmierer gesehen wird, der dann den Code korrigiert. Daher glaube ich jetzt, dass sie beide RuntimeError auslösen sollten. Es gibt einige Präzedenzfälle dafür: sie wird vom Kern-Python-Code in Situationen ausgelöst, in denen endlose Rekursion erkannt wird, und für uninitialisierte Objekte (und für eine Vielzahl von verschiedenen Bedingungen).

2. Oren Tirosh hat vorgeschlagen, die send()-Methode in feed() umzubenennen, um die Kompatibilität mit der *Consumer-Schnittstelle* zu gewährleisten (siehe http://effbot.org/zone/consumer.htm für die Spezifikation).

   Bei näherer Betrachtung der Consumer-Schnittstelle scheint es jedoch, dass die gewünschten Semantiken für feed() von denen für send() abweichen, da send() bei einem gerade gestarteten Generator nicht sinnvoll aufgerufen werden kann. Außerdem beinhaltet die derzeit definierte Consumer-Schnittstelle keine Handhabung für StopIteration.

   Daher scheint es wahrscheinlich nützlicher zu sein, einen einfachen Dekorator zu erstellen, der eine Generatorfunktion umschließt, um sie an die Consumer-Schnittstelle anzupassen. Zum Beispiel könnte sie den Generator mit einem anfänglichen next()-Aufruf *aufwärmen*, StopIteration abfangen und vielleicht sogar reset() bereitstellen, indem die Generatorfunktion erneut aufgerufen wird.

Beispiele

1. Ein einfacher *Consumer*-Dekorator, der eine Generatorfunktion automatisch bis zu ihrem ersten Yield-Punkt fortsetzt, wenn sie initial aufgerufen wird.

   def consumer(func):
       def wrapper(*args,**kw):
           gen = func(*args, **kw)
           gen.next()
           return gen
       wrapper.__name__ = func.__name__
       wrapper.__dict__ = func.__dict__
       wrapper.__doc__  = func.__doc__
       return wrapper
   

2. Ein Beispiel für die Verwendung des *Consumer*-Dekorators zur Erstellung eines *Reverse Generators*, der Bilder empfängt und Thumbnail-Seiten erstellt, die an einen anderen Consumer gesendet werden. Funktionen wie diese können verkettet werden, um effiziente Verarbeitungspipelines von *Consumern* zu bilden, von denen jeder einen komplexen internen Zustand haben kann.

   @consumer
   def thumbnail_pager(pagesize, thumbsize, destination):
       while True:
           page = new_image(pagesize)
           rows, columns = pagesize / thumbsize
           pending = False
           try:
               for row in xrange(rows):
                   for column in xrange(columns):
                       thumb = create_thumbnail((yield), thumbsize)
                       page.write(
                           thumb, col*thumbsize.x, row*thumbsize.y )
                       pending = True
           except GeneratorExit:
               # close() was called, so flush any pending output
               if pending:
                   destination.send(page)
   
               # then close the downstream consumer, and exit
               destination.close()
               return
           else:
               # we finished a page full of thumbnails, so send it
               # downstream and keep on looping
               destination.send(page)
   
   @consumer
   def jpeg_writer(dirname):
       fileno = 1
       while True:
           filename = os.path.join(dirname,"page%04d.jpg" % fileno)
           write_jpeg((yield), filename)
           fileno += 1
   
   
   # Put them together to make a function that makes thumbnail
   # pages from a list of images and other parameters.
   #
   def write_thumbnails(pagesize, thumbsize, images, output_dir):
       pipeline = thumbnail_pager(
           pagesize, thumbsize, jpeg_writer(output_dir)
       )
   
       for image in images:
           pipeline.send(image)
   
       pipeline.close()
   

3. Ein einfacher *Coroutinen-Scheduler* oder *Trampolin*, der es Coroutinen ermöglicht, andere Coroutinen aufzurufen, indem die Coroutine, die sie aufrufen möchten, als Wert geliefert wird. Jeder Nicht-Generator-Wert, der von einer Coroutine geliefert wird, wird an die Coroutine zurückgegeben, die diejenige aufgerufen hat, die den Wert geliefert hat. Ebenso wird, wenn eine Coroutine eine Ausnahme auslöst, die Ausnahme an ihren *Aufrufer* weitergegeben. Tatsächlich emuliert dieses Beispiel einfache Tasklets, wie sie in Stackless Python verwendet werden, solange Sie einen Yield-Ausdruck verwenden, um Routinen aufzurufen, die ansonsten *blockieren* würden. Dies ist nur ein sehr einfaches Beispiel, und weitaus ausgefeiltere Scheduler sind möglich. (Zum Beispiel implementieren das bestehende GTasklet-Framework für Python (http://www.gnome.org/~gjc/gtasklet/gtasklets.html) und das peak.events-Framework (http://peak.telecommunity.com/) bereits ähnliche Scheduling-Fähigkeiten, müssen aber derzeit umständliche Workarounds für die Unfähigkeit verwenden, Werte oder Ausnahmen in Generatoren zu übergeben.)

   import collections
   
   class Trampoline:
       """Manage communications between coroutines"""
   
       running = False
   
       def __init__(self):
           self.queue = collections.deque()
   
       def add(self, coroutine):
           """Request that a coroutine be executed"""
           self.schedule(coroutine)
   
       def run(self):
           result = None
           self.running = True
           try:
               while self.running and self.queue:
                  func = self.queue.popleft()
                  result = func()
               return result
           finally:
               self.running = False
   
       def stop(self):
           self.running = False
   
       def schedule(self, coroutine, stack=(), val=None, *exc):
           def resume():
               value = val
               try:
                   if exc:
                       value = coroutine.throw(value,*exc)
                   else:
                       value = coroutine.send(value)
               except:
                   if stack:
                       # send the error back to the "caller"
                       self.schedule(
                           stack[0], stack[1], *sys.exc_info()
                       )
                   else:
                       # Nothing left in this pseudothread to
                       # handle it, let it propagate to the
                       # run loop
                       raise
   
               if isinstance(value, types.GeneratorType):
                   # Yielded to a specific coroutine, push the
                   # current one on the stack, and call the new
                   # one with no args
                   self.schedule(value, (coroutine,stack))
   
               elif stack:
                   # Yielded a result, pop the stack and send the
                   # value to the caller
                   self.schedule(stack[0], stack[1], value)
   
               # else: this pseudothread has ended
   
           self.queue.append(resume)
   

4. Ein einfacher *Echo*-Server und Code, um ihn mithilfe eines Trampolins auszuführen (setzt das Vorhandensein von nonblocking_read, nonblocking_write und anderen I/O-Coroutinen voraus, die z. B. ConnectionLost auslösen, wenn die Verbindung geschlossen wird).

   # coroutine function that echos data back on a connected
   # socket
   #
   def echo_handler(sock):
       while True:
           try:
               data = yield nonblocking_read(sock)
               yield nonblocking_write(sock, data)
           except ConnectionLost:
               pass  # exit normally if connection lost
   
   # coroutine function that listens for connections on a
   # socket, and then launches a service "handler" coroutine
   # to service the connection
   #
   def listen_on(trampoline, sock, handler):
       while True:
           # get the next incoming connection
           connected_socket = yield nonblocking_accept(sock)
   
           # start another coroutine to handle the connection
           trampoline.add( handler(connected_socket) )
   
   # Create a scheduler to manage all our coroutines
   t = Trampoline()
   
   # Create a coroutine instance to run the echo_handler on
   # incoming connections
   #
   server = listen_on(
       t, listening_socket("localhost","echo"), echo_handler
   )
   
   # Add the coroutine to the scheduler
   t.add(server)
   
   # loop forever, accepting connections and servicing them
   # "in parallel"
   #
   t.run()
   

Referenzimplementierung

Ein Prototyp-Patch, der alle in diesem PEP beschriebenen Features implementiert, ist als SourceForge-Patch #1223381 verfügbar (https://bugs.python.org/issue1223381).

Dieser Patch wurde am 01.-02. August 2005 in CVS committet.

Danksagungen

Raymond Hettinger (PEP 288) und Samuele Pedroni (PEP 325) schlugen zuerst formell die Ideen der Kommunikation von Werten oder Ausnahmen in Generatoren und die Fähigkeit, Generatoren zu *schließen*, vor. Timothy Delaney schlug den Titel dieses PEP vor, und Steven Bethard half bei der Bearbeitung einer früheren Version. Siehe auch den Abschnitt "Danksagungen" von PEP 340.

Referenzen

TBD.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.