Das Modul „interpreters“

Das Modul interpreters wird eine High-Level-Schnittstelle zur Funktionalität mehrerer Interpreter bereitstellen und eine neue Low-Level- _interpreters (ähnlich wie das Modul threading) wrappen. Siehe den Abschnitt Beispiele für konkrete Nutzung und Anwendungsfälle.

Zusätzlich zur Bereitstellung der bestehenden (in CPython) Unterstützung für mehrere Interpreter wird das Modul auch einen grundlegenden Mechanismus für die Übergabe von Daten zwischen Interpretern unterstützen. Dies beinhaltet das Setzen von „teilbaren“ Objekten im Modul __main__ eines Ziel-Subinterpreters. Einige dieser Objekte, wie os.pipe(), können zur weiteren Kommunikation verwendet werden. Das Modul wird auch eine minimale Implementierung von „Kanälen“ als Demonstration der Cross-Interpreter-Kommunikation bereitstellen.

Beachten Sie, dass Objekte nicht zwischen Interpretern geteilt werden, da sie an den Interpreter gebunden sind, in dem sie erstellt wurden. Stattdessen werden die Daten der Objekte zwischen Interpretern übergeben. Weitere Details zum Teilen/Kommunizieren zwischen Interpretern finden Sie in den Abschnitten Gemeinsame Daten und API für die Kommunikation.

API-Zusammenfassung für das Modul interpreters

Hier ist eine Zusammenfassung der API für das Modul interpreters. Eine detailliertere Erklärung der vorgeschlagenen Klassen und Funktionen finden Sie im Abschnitt „interpreters“ Modul API unten.

Zum Erstellen und Verwenden von Interpretern

Für die Kommunikation zwischen Interpretern

concurrent.futures.InterpreterPoolExecutor

Ein Executor wird hinzugefügt, der ThreadPoolExecutor erweitert, um Thread-Aufgaben in Subinterpretern auszuführen. Anfangs werden die einzigen unterstützten Aufgaben das sein, was Interpreter.exec() akzeptiert (z. B. ein Skript als str). Wir könnten jedoch auch einige Funktionen unterstützen, sowie schließlich eine separate Methode zum Picklen der Aufgabe und der Argumente, um Reibungsverluste zu reduzieren (auf Kosten der Leistung für kurzlaufende Aufgaben).

Hilfe für Wartende von Erweiterungsmodulen

In der Praxis wird ein Erweiterungsmodul, das eine Multi-Phase-Initialisierung implementiert (PEP 489), als isoliert betrachtet und ist somit mit mehreren Interpretern kompatibel. Andernfalls ist es „inkompatibel“.

Viele Erweiterungsmodule sind immer noch inkompatibel. Die Wartenden und Benutzer solcher Erweiterungsmodule werden beide profitieren, wenn sie aktualisiert werden, um mehrere Interpreter zu unterstützen. Bis dahin können sich Benutzer durch Fehler bei der Verwendung mehrerer Interpreter verwirrt fühlen, was sich negativ auf die Wartenden von Erweiterungen auswirken könnte. Siehe Bedenken unten.

Um diese Auswirkungen abzumildern und die Kompatibilität zu beschleunigen, werden wir Folgendes tun:

• klarstellen, dass Erweiterungsmodule nicht verpflichtet sind, die Verwendung in mehreren Interpretern zu unterstützen
• einen ImportError auslösen, wenn ein inkompatibles Modul in einem Subinterpreter importiert wird
• Ressourcen bereitstellen (z. B. Dokumente), um Wartende bei der Erreichung der Kompatibilität zu unterstützen
• die Wartenden von Cython und den am häufigsten verwendeten Erweiterungsmodulen (auf PyPI) kontaktieren, um Feedback zu erhalten und möglicherweise Unterstützung anzubieten

Isolierten Code im aktuellen Betriebssystem-Thread ausführen

interp = interpreters.create()
print('before')
interp.exec('print("during")')
print('after')

In einem anderen Thread ausführen

interp = interpreters.create()
def run():
    interp.exec('print("during")')
t = threading.Thread(target=run)
print('before')
t.start()
t.join()
print('after')

Einen Interpreter vorab füllen

interp = interpreters.create()
interp.exec(tw.dedent("""
    import some_lib
    import an_expensive_module
    some_lib.set_up()
    """))
wait_for_request()
interp.exec(tw.dedent("""
    some_lib.handle_request()
    """))

Ausnahmebehandlung

interp = interpreters.create()
try:
    interp.exec(tw.dedent("""
        raise KeyError
        """))
except interpreters.RunFailedError as exc:
    print(f"got the error from the subinterpreter: {exc}")

Ausnahme erneut auslösen

interp = interpreters.create()
try:
    try:
        interp.exec(tw.dedent("""
            raise KeyError
            """))
    except interpreters.RunFailedError as exc:
        raise exc.__cause__
except KeyError:
    print("got a KeyError from the subinterpreter")

Beachten Sie, dass dieses Muster ein Kandidat für spätere Verbesserungen ist.

Mit dem __main__-Namespace interagieren

interp = interpreters.create()
interp.set_main_attrs(a=1, b=2)
interp.exec(tw.dedent("""
    res = do_something(a, b)
    """))
res = interp.get_main_attr('res')

Synchronisation mittels einer OS-Pipe

interp = interpreters.create()
r1, s1 = os.pipe()
r2, s2 = os.pipe()

def task():
    interp.exec(tw.dedent(f"""
        import os
        os.read({r1}, 1)
        print('during B')
        os.write({s2}, '')
        """))

t = threading.thread(target=task)
t.start()
print('before')
os.write(s1, '')
print('during A')
os.read(r2, 1)
print('after')
t.join()

Einen File Descriptor teilen

interp = interpreters.create()
with open('spamspamspam') as infile:
    interp.set_main_attrs(fd=infile.fileno())
    interp.exec(tw.dedent(f"""
        import os
        for line in os.fdopen(fd):
            print(line)
        """))

Objekte per Pickle übergeben

interp = interpreters.create()
r, s = os.pipe()
interp.exec(tw.dedent(f"""
    import os
    import pickle
    reader = {r}
    """))
interp.exec(tw.dedent("""
        data = b''
        c = os.read(reader, 1)
        while c != b'\x00':
            while c != b'\x00':
                data += c
                c = os.read(reader, 1)
            obj = pickle.loads(data)
            do_something(obj)
            c = os.read(reader, 1)
        """))
for obj in input:
    data = pickle.dumps(obj)
    os.write(s, data)
    os.write(s, b'\x00')
os.write(s, b'\x00')

Standardausgabe eines Interpreters erfassen

interp = interpreters.create()
stdout = io.StringIO()
with contextlib.redirect_stdout(stdout):
    interp.exec(tw.dedent("""
        print('spam!')
        """))
assert(stdout.getvalue() == 'spam!')

# alternately:
interp.exec(tw.dedent("""
    import contextlib, io
    stdout = io.StringIO()
    with contextlib.redirect_stdout(stdout):
        print('spam!')
    captured = stdout.getvalue()
    """))
captured = interp.get_main_attr('captured')
assert(captured == 'spam!')

Eine Pipe (os.pipe()) könnte ähnlich verwendet werden.

Ein Modul ausführen

interp = interpreters.create()
main_module = mod_name
interp.exec(f'import runpy; runpy.run_module({main_module!r})')

Als Skript ausführen (einschließlich Zip-Archive & Verzeichnisse)

interp = interpreters.create()
main_script = path_name
interp.exec(f"import runpy; runpy.run_path({main_script!r})")

Einen Kanal zur Kommunikation nutzen

tasks_recv, tasks = interpreters.create_channel()
results, results_send = interpreters.create_channel()

def worker():
    interp = interpreters.create()
    interp.set_main_attrs(tasks=tasks_recv, results=results_send)
    interp.exec(tw.dedent("""
        def handle_request(req):
            ...

        def capture_exception(exc):
            ...

        while True:
            try:
                req = tasks.recv()
            except Exception:
                # channel closed
                break
            try:
                res = handle_request(req)
            except Exception as exc:
                res = capture_exception(exc)
            results.send_nowait(res)
        """))
threads = [threading.Thread(target=worker) for _ in range(20)]
for t in threads:
    t.start()

requests = ...
for req in requests:
    tasks.send(req)
tasks.close()

for t in threads:
    t.join()

Ein memoryview teilen (imagine map-reduce)

data, chunksize = read_large_data_set()
buf = memoryview(data)
numchunks = (len(buf) + 1) / chunksize
results = memoryview(b'\0' * numchunks)

tasks_recv, tasks = interpreters.create_channel()

def worker():
    interp = interpreters.create()
    interp.set_main_attrs(data=buf, results=results, tasks=tasks_recv)
    interp.exec(tw.dedent("""
        while True:
            try:
                req = tasks.recv()
            except Exception:
                # channel closed
                break
            resindex, start, end = req
            chunk = data[start: end]
            res = reduce_chunk(chunk)
            results[resindex] = res
        """))
t = threading.Thread(target=worker)
t.start()

for i in range(numchunks):
    if not workers_running():
        raise ...
    start = i * chunksize
    end = start + chunksize
    if end > len(buf):
        end = len(buf)
    tasks.send((start, end, i))
tasks.close()
t.join()

use_results(results)

Bedenken

• „Subinterpreter sind die Mühe nicht wert“

Einige argumentierten, dass Subinterpreter keinen ausreichenden Nutzen bieten, um sie zu einem offiziellen Teil von Python zu machen. Das Hinzufügen von Funktionen zur Sprache (oder Standardbibliothek) hat die Kosten, die Größe der Sprache zu erhöhen. Eine Ergänzung muss sich also selbst amortisieren.

In diesem Fall bietet die Unterstützung mehrerer Interpreter ein neuartiges Nebenläufigkeitsmodell, das auf isolierte Ausführungsthreads fokussiert ist. Darüber hinaus bieten sie eine Gelegenheit für Änderungen in CPython, die die gleichzeitige Nutzung mehrerer CPU-Kerne ermöglichen (derzeit durch das GIL verhindert – siehe PEP 684).

Alternativen zu Subinterpretern sind Threading, Async und Multiprocessing. Threading wird durch das GIL begrenzt und Async ist nicht die richtige Lösung für jedes Problem (noch für jede Person). Multiprocessing ist ebenfalls in einigen, aber nicht allen Situationen wertvoll. Direkte IPC (anstatt über das multiprocessing-Modul) bietet ähnliche Vorteile, jedoch mit demselben Vorbehalt.

Bemerkenswerterweise sind Subinterpreter kein Ersatz für die oben genannten. Sicherlich überschneiden sie sich in einigen Bereichen, aber die Vorteile von Subinterpretern umfassen Isolation und (potenziell) Leistung. Insbesondere bieten Subinterpreter einen direkten Weg zu einem alternativen Nebenläufigkeitsmodell (z. B. CSP), das anderswo erfolgreich war und einige Python-Benutzer ansprechen wird. Das ist der Kernwert, den das Modul interpreters bereitstellen wird.

• „Standardbibliotheksunterstützung für mehrere Interpreter belastet C-Erweiterungsautoren zusätzlich“

Im Abschnitt Interpreter-Isolation unten identifizieren wir Wege, auf denen die Isolation in CPythons Subinterpretern unvollständig ist. Am bemerkenswertesten sind Erweiterungsmodule, die C-Globale zur Speicherung interner Zustände verwenden. (PEP 3121 und PEP 489 bieten eine Lösung für dieses Problem, gefolgt von einigen zusätzlichen APIs, die die Effizienz verbessern, z. B. PEP 573).

Folglich könnten Projekte, die Erweiterungsmodule veröffentlichen, mit einer erhöhten Wartungslast konfrontiert sein, wenn ihre Benutzer Subinterpreter zu verwenden beginnen, wo ihre Module möglicherweise fehlschlagen. Diese Situation ist auf Module beschränkt, die C-Globale verwenden (oder Bibliotheken verwenden, die C-Globale verwenden) zur Speicherung interner Zustände. Für Numpy beträgt die gemeldete Fehlerquote einen alle 6 Monate. [bug-rate]

Letztendlich kommt es auf die Frage an, wie oft es in der Praxis ein Problem sein wird: wie viele Projekte betroffen sein werden, wie oft ihre Benutzer betroffen sein werden, wie hoch die zusätzliche Wartungslast für Projekte sein wird und wie hoch der Gesamtnutzen von Subinterpretern ist, um diese Kosten auszugleichen. Die Position dieses PEP ist, dass die tatsächliche zusätzliche Wartungslast gering sein und weit unter der Schwelle liegen wird, bei der Subinterpreter sich lohnen.

• „Das Erstellen einer neuen Nebenläufigkeits-API erfordert viel mehr Gedanken und Experimente, daher sollte das neue Modul nicht sofort in die Standardbibliothek aufgenommen werden, wenn überhaupt.“

Die Einführung einer API für ein neues Nebenläufigkeitsmodell, wie es bei asyncio der Fall war, ist ein extrem großes Projekt, das viel sorgfältige Überlegung erfordert. Es ist nichts, was so einfach getan werden kann, wie dieser PEP vorschlägt, und verdient wahrscheinlich viel Zeit auf PyPI, um sich zu entwickeln. (Siehe Nathaniels Beitrag auf python-dev.)

Dieser PEP schlägt jedoch keine neue Nebenläufigkeits-API vor. Höchstens exponiert er minimale Werkzeuge (z. B. Subinterpreter, Kanäle), die verwendet werden können, um Code zu schreiben, der Mustern folgt, die mit (relativ) neuen Nebenläufigkeitsmodellen für Python verbunden sind Nebenläufigkeitsmodelle. Diese Werkzeuge könnten auch als Grundlage für APIs für solche Nebenläufigkeitsmodelle verwendet werden. Auch hier schlägt dieser PEP keine solche API vor.

• „Es hat keinen Sinn, Subinterpreter zu exponieren, wenn sie immer noch das GIL teilen.“
• „Die Anstrengung, das GIL pro Interpreter zu machen, ist störend und riskant.“

Ein häufiges Missverständnis ist, dass dieser PEP auch ein Versprechen enthält, dass Interpreter das GIL nicht mehr teilen werden. Wenn das geklärt ist, ist die nächste Frage: „Was ist der Sinn?“ Diese wird bereits ausführlich in diesem PEP beantwortet. Nur zur Klarstellung: Der Wert liegt in

* increase exposure of the existing feature, which helps improve
  the code health of the entire CPython runtime
* expose the (mostly) isolated execution of interpreters
* preparation for per-interpreter GIL
* encourage experimentation

• „Datenaustausch kann sich negativ auf die Cache-Leistung in Multi-Core-Szenarien auswirken.“

(Siehe [cache-line-ping-pong].)

Das sollte im Moment kein Problem sein, da wir keine unmittelbaren Pläne haben, Daten zwischen Interpretern tatsächlich zu teilen, sondern uns auf das Kopieren konzentrieren.

Nebenläufigkeit

Nebenläufigkeit ist ein anspruchsvolles Gebiet der Softwareentwicklung. Jahrzehnte der Forschung und Praxis haben zu einer breiten Vielfalt von Nebenläufigkeitsmodellen geführt, jedes mit unterschiedlichen Zielen. Die meisten konzentrieren sich auf Korrektheit und Benutzerfreundlichkeit.

Eine Klasse von Nebenläufigkeitsmodellen konzentriert sich auf isolierte Ausführungsthreads, die über ein gewisses Nachrichtenweiterleitungsschema interoperieren. Ein bemerkenswertes Beispiel sind Communicating Sequential Processes [CSP] (auf dem Go's Nebenläufigkeit grob basiert). Die inhärente Isolation von CPythons Interpretern macht sie gut geeignet für diesen Ansatz.

Gemeinsame Daten

CPyhtons Interpreter sind von Natur aus isoliert (mit nachstehend erläuterten Vorbehalten), im Gegensatz zu Threads. Daher funktioniert derselbe Ansatz der Kommunikation über Shared Memory nicht. Ohne eine Alternative ist die effektive Nutzung von Nebenläufigkeit über mehrere Interpreter erheblich eingeschränkt.

Die größte Herausforderung hierbei ist, dass das Teilen von Objekten zwischen Interpretern aufgrund verschiedener Einschränkungen hinsichtlich Objekteigentümerschaft, Sichtbarkeit und Veränderbarkeit komplex ist. Auf konzeptioneller Ebene ist es einfacher, Nebenläufigkeit zu verstehen, wenn Objekte nur zu einem Zeitpunkt in einem Interpreter existieren. Auf technischer Ebene schränkt das aktuelle Speichermodell von CPython ein, wie Python-Objekte sicher zwischen Interpretern geteilt werden können; effektiv sind Objekte an den Interpreter gebunden, in dem sie erstellt wurden. Darüber hinaus nimmt die Komplexität der Objekt-Teilung zu, wenn Interpreter isolierter werden, z. B. nach der GIL-Entfernung (obwohl dies für einige „unsterbliche“ Objekte etwas gemildert wird (siehe PEP 683).

Folglich muss der Mechanismus für die gemeinsame Nutzung sorgfältig abgewogen werden. Es gibt eine Reihe gültiger Lösungen, von denen mehrere für die Unterstützung in Pythons Standardbibliothek und C-API geeignet sein könnten. Jede solche Lösung wird wahrscheinlich viele Merkmale mit den anderen teilen.

In der Zwischenzeit schlagen wir hier eine minimale Lösung vor (Interpreter.set_main_attrs()), die einen Präzedenzfall dafür schafft, wie Objekte geteilt werden. Wichtiger ist, dass sie die Einführung fortgeschrittenerer Ansätze ermöglicht und diese koexistieren und kooperieren lässt. Teilweise um dies zu demonstrieren, werden wir eine grundlegende Implementierung von „Kanälen“ bereitstellen, als eine etwas fortgeschrittenere Teilen-Lösung.

Separate Vorschläge können abdecken

• die Hinzufügung einer öffentlichen C-API basierend auf der Implementierung von Interpreter.set_main_attrs()
• die Hinzufügung anderer Teilungsansätze zum Modul „interpreters“

Das grundlegende ermöglichende Merkmal für die Kommunikation ist, dass die meisten Objekte in eine Kodierung von zugrunde liegenden Rohdaten umgewandelt werden können, die sicher zwischen Interpretern übergeben werden kann. Zum Beispiel kann ein int-Objekt in einen C long-Wert umgewandelt, an einen anderen Interpreter gesendet und dort wieder in ein int-Objekt umgewandelt werden. Als weiteres Beispiel kann None unverändert übergeben werden.

Unabhängig davon liegt der Aufwand, den besten Weg hierfür zu bestimmen, größtenteils außerhalb des Rahmens dieses PEP. In der Zwischenzeit beschreibt dieser Vorschlag eine grundlegende Übergangslösung mit Pipes (os.pipe()) und bietet eine dedizierte Fähigkeit („Kanäle“). Siehe API für die Kommunikation unten.

Interpreter-Isolation

CPyhtons Interpreter sollen streng voneinander isoliert sein. Jeder Interpreter hat seine eigene Kopie aller Module, Klassen, Funktionen und Variablen. Das Gleiche gilt für den Zustand in C, einschließlich Erweiterungsmodulen. Die CPython C-API-Dokumente erklären mehr. [caveats]

Es gibt jedoch Möglichkeiten, wie Interpreter einige Zustände teilen. Erstens bleibt ein Teil des prozessglobalen Zustands gemeinsam genutzt

• Dateideskriptoren
• Low-Level-Umgebungsvariablen
• Prozessspeicher (obwohl Allocatoren isoliert sind)
• eingebaute Typen (z. B. dict, bytes)
• Singletons (z. B. None)
• zugrunde liegende statische Moduldaten (z. B. Funktionen) für eingebaute/Erweiterungs-/eingefrorene Module

Es gibt keine Pläne, dies zu ändern.

Zweitens ist die Isolation aufgrund von Fehlern oder Implementierungen, die Subinterpreter nicht berücksichtigten, fehlerhaft. Dazu gehören Dinge wie Erweiterungsmodule, die auf C-Globale angewiesen sind. [cryptography] In diesen Fällen sollten Fehler gemeldet werden (einige sind bereits gemeldet)

• Readline-Modul-Hook-Funktionen (http://bugs.python.org/issue4202)
• Speicherlecks bei Re-Init (http://bugs.python.org/issue21387)

Schließlich fehlt aufgrund des aktuellen Designs von CPython eine gewisse potenzielle Isolation. Verbesserungen werden derzeit vorgenommen, um Lücken in diesem Bereich zu schließen

• Erweiterungen, die die PyGILState_* API verwenden, sind einigermaßen inkompatibel [gilstate]

Bestehende Nutzung

Die Unterstützung mehrerer Interpreter war keine weit verbreitete Funktion. Tatsächlich gab es nur eine Handvoll dokumentierter Fälle weit verbreiteter Nutzung, darunter mod_wsgi, OpenStack Ceph und JEP. Einerseits geben diese Fälle Vertrauen, dass die bestehende Unterstützung für mehrere Interpreter relativ stabil ist. Andererseits gibt es keine große Stichprobengröße, um den Nutzen der Funktion zu beurteilen.

Nicht abgefangene Ausnahmen

Bezüglich nicht abgefangener Ausnahmen in Interpreter.exec() stellten wir fest, dass sie „effektiv“ in den Code propagiert werden, in dem interp.exec() aufgerufen wurde. Um Ausnahmen (und Tracebacks) zwischen Interpretern nicht durchsickern zu lassen, erstellen wir eine Ersatzdarstellung der Ausnahme und ihres Tracebacks (siehe traceback.TracebackException), setzen sie auf __cause__ einer neuen interpreters.RunFailedError und lösen diese aus.

Das direkte Auslösen (eines Proxys der) Ausnahme ist problematisch, da es schwieriger ist, zwischen einem Fehler im interp.exec()-Aufruf und einer nicht abgefangenen Ausnahme aus dem Subinterpreter zu unterscheiden.

Teilbare Typen

Ein Objekt ist „teilbar“, wenn sein Typ teilbare Instanzen unterstützt. Der Typ muss ein neues internes Protokoll implementieren, das verwendet wird, um ein Objekt in Interpreter-unabhängige Daten zu konvertieren und dann zurück in ein Objekt auf der anderen Seite zu konvertieren. Siehe auch is_shareable() oben.

Eine minimale Menge einfacher, unveränderlicher eingebauter Typen wird anfangs unterstützt, einschließlich:

• Keine
• bool
• bytes
• str
• int
• float

Wir werden anfangs auch eine kleine Anzahl komplexer Typen unterstützen:

• memoryview, um PEP 3118-Puffer zu teilen
• Kanäle

Weitere eingebaute Typen können später unterstützt werden, ob komplex oder nicht. Die Begrenzung der anfänglichen teilbaren Typen ist eine praktische Angelegenheit, die die potenzielle Komplexität der anfänglichen Implementierung reduziert. Es gibt eine Reihe von Strategien, die wir zukünftig verfolgen könnten, um unterstützte Objekte zu erweitern, sobald wir mehr Erfahrung mit Interpreter-Isolation haben.

In der Zwischenzeit wird ein separater Vorschlag die öffentliche Bereitstellung des internen Protokolls (und der C-API) diskutieren, das von Interpreter.set_main_attrs() verwendet wird. Mit diesem Protokoll könnten Erweiterungsmodule Unterstützung für andere Typen hinzufügen.

Kanäle

Das Modul interpreters wird eine dedizierte Lösung für die Übergabe von Objektdaten zwischen Interpretern enthalten: Kanäle. Sie sind teilweise im Modul enthalten, um einen einfacheren Mechanismus als die Verwendung von os.pipe() bereitzustellen und teilweise, um zu demonstrieren, wie Bibliotheken Interpreter.set_main_attrs() und das von ihr verwendete Protokoll nutzen können.

Ein Kanal ist ein Simplex-FIFO. Es ist ein grundlegender, optionaler Mechanismus zum Teilen von Daten, der von Pipes, Queues und CSP-Kanälen inspiriert ist. [fifo] Der Hauptunterschied zu Pipes besteht darin, dass Kanäle mit null oder mehr Interpretern auf beiden Seiten verbunden werden können. Wie Queues, die ebenfalls Many-to-Many sind, sind Kanäle gepuffert (obwohl sie auch Methoden mit unbuffered Semantik anbieten).

Kanäle haben zwei Operationen: Senden und Empfangen. Ein Schlüsselmerkmal dieser Operationen ist, dass Kanäle Daten übertragen, die von Python-Objekten abgeleitet sind, und nicht die Objekte selbst. Wenn Objekte gesendet werden, werden ihre Daten extrahiert. Wenn der "Objekt" im anderen Interpreter empfangen wird, werden die Daten zurück in ein Objekt konvertiert, das diesem Interpreter gehört.

Damit dies funktioniert, wird der mutable gemeinsame Zustand vom Python-Runtime verwaltet, nicht von einem der Interpreter. Anfangs werden wir nur einen Objekttyp für den gemeinsamen Zustand unterstützen: die von interpreters.create_channel() bereitgestellten Kanäle. Kanäle wiederum werden die Übergabe von Objekten zwischen Interpretern sorgfältig verwalten.

Dieser Ansatz, einschließlich der Beibehaltung einer minimalen API, hilft uns, weitere Komplexität vor Python-Benutzern zu verbergen.

Das Modul interpreters bietet die folgende Funktion in Bezug auf Kanäle.

create_channel() -> (RecvChannel, SendChannel):

   Create a new channel and return (recv, send), the RecvChannel
   and SendChannel corresponding to the ends of the channel.

   Both ends of the channel are supported "shared" objects (i.e.
   may be safely shared by different interpreters.  Thus they
   may be set using "Interpreter.set_main_attrs()".

Das Modul bietet auch die folgenden klassenbezogenen Klassen.

class RecvChannel(id):

   The receiving end of a channel.  An interpreter may use this to
   receive objects from another interpreter.  Any type supported by
   Interpreter.set_main_attrs() will be supported here, though at
   first only a few of the simple, immutable builtin types
   will be supported.

   id -> int:

      The channel's unique ID.  The "send" end has the same one.

   recv(*, timeout=None):

      Return the next object from the channel.  If none have been
      sent then wait until the next send (or until the timeout is hit).

      At the least, the object will be equivalent to the sent object.
      That will almost always mean the same type with the same data,
      though it could also be a compatible proxy.  Regardless, it may
      use a copy of that data or actually share the data.  That's up
      to the object's type.

   recv_nowait(default=None):

      Return the next object from the channel.  If none have been
      sent then return the default.  Otherwise, this is the same
      as the "recv()" method.


class SendChannel(id):

   The sending end of a channel.  An interpreter may use this to
   send objects to another interpreter.  Any type supported by
   Interpreter.set_main_attrs() will be supported here, though
   at first only a few of the simple, immutable builtin types
   will be supported.

   id -> int:

      The channel's unique ID.  The "recv" end has the same one.

   send(obj, *, timeout=None):

      Send the object (i.e. its data) to the "recv" end of the
      channel.  Wait until the object is received.  If the object
      is not shareable then ValueError is raised.

      The builtin memoryview is supported, so sending a buffer
      across involves first wrapping the object in a memoryview
      and then sending that.

   send_nowait(obj):

      Send the object to the "recv" end of the channel.  This
      behaves the same as "send()", except for the waiting part.
      If no interpreter is currently receiving (waiting on the
      other end) then queue the object and return False.  Otherwise
      return True.

Vorbehalte bei geteilten Objekten

Auch hier werden Python-Objekte nicht zwischen Interpretern geteilt. In einigen Fällen werden die Daten, die diese Objekte umschließen, jedoch tatsächlich geteilt und nicht nur kopiert. Ein Beispiel hierfür könnten PEP 3118-Puffer sein.

In diesen Fällen wird das Objekt im ursprünglichen Interpreter so lange am Leben gehalten, bis die geteilten Daten im anderen Interpreter nicht mehr verwendet werden. Dann kann die Objektzerstörung wie gewohnt im ursprünglichen Interpreter stattfinden, zusammen mit den zuvor geteilten Daten.

Bequemlichkeits-API hinzufügen

Es gibt eine Reihe von Dingen, die hypothetische Probleme mit dem neuen Modul glätten könnten.

• etwas wie Interpreter.run() oder Interpreter.call() hinzufügen, das interp.exec() aufruft und auf Pickle zurückfällt.
• auf Pickle in Interpreter.set_main_attrs() und Interpreter.get_main_attr() zurückfallen.

Dies wäre einfach zu tun, wenn sich dies als Schwachstelle erweist.

Verwechslungen bezüglich der Ausführung von Interpretern im aktuellen Thread vermeiden

Ein häufiger Verwirrungspunkt war, dass Interpreter.exec() im aktuellen Betriebssystem-Thread ausgeführt wird und den aktuellen Python-Thread vorübergehend blockiert. Es könnte sich lohnen, etwas zu tun, um diese Verwirrung zu vermeiden.

Einige mögliche Lösungen für dieses hypothetische Problem:

• Standardmäßig in einem neuen Thread ausführen?
• hinzufügen von Interpreter.exec_in_thread()?
• hinzufügen von Interpreter.exec_in_current_thread()?

In früheren Versionen dieses PEP war die Methode interp.run(). Die einfache Änderung zu interp.exec() allein wird wahrscheinlich die Verwirrung ausreichend reduzieren, wenn sie mit der Aufklärung der Benutzer durch die Dokumentation kombiniert wird. Wenn es sich als echtes Problem herausstellt, können wir zu diesem Zeitpunkt eine der Alternativen verfolgen.

„Running“ vs. „hat Threads“ klären

Interpreter.is_running() bezieht sich speziell darauf, ob Interpreter.exec() (oder ähnliches) irgendwo läuft. Sie sagt nichts darüber aus, ob der Interpreter Sub-Threads laufen hat. Diese Information könnte hilfreich sein.

Einige Dinge, die wir tun könnten:

• umbenennen von Interpreter.is_running() zu Interpreter.is_running_main()
• hinzufügen von Interpreter.has_threads(), um Interpreter.is_running() zu ergänzen.
• erweitern auf Interpreter.is_running(main=True, threads=False)

Keines davon ist dringend und jedes könnte später, wenn gewünscht, durchgeführt werden.

Eine Dunder-Methode zum Teilen

Wir könnten eine spezielle Methode wie __xid__ hinzufügen, die tp_xid entspricht. Zumindest würde sie es Python-Typen ermöglichen, ihre Instanzen in einen anderen Typ zu konvertieren, der tp_xid implementiert.

Das Problem ist, dass die Exposition dieser Funktionalität gegenüber Python-Code ein gewisses Maß an Komplexität mit sich bringt, das noch nicht erforscht wurde, und es gibt keinen überzeugenden Grund, diese Komplexität zu untersuchen.

Interpreter.call()

Es wäre praktisch, bestehende Funktionen direkt in Subinterpretern auszuführen. Interpreter.exec() könnte angepasst werden, um dies zu unterstützen, oder eine Methode call() könnte hinzugefügt werden.

Interpreter.call(f, *args, **kwargs)

Dies leidet unter demselben Problem wie das Teilen von Objekten zwischen Interpretern über Queues. Die minimale Lösung (Ausführen eines Quelltextes) reicht aus, damit wir die Funktion herausbringen können, wo sie erforscht werden kann.

Interpreter.run_in_thread()

Diese Methode würde einen interp.exec()-Aufruf für Sie in einem Thread ausführen. Dies nur mit threading.Thread und interp.exec() zu tun, ist relativ trivial, daher haben wir es weggelassen.

Synchronisationsprimitive

Das Modul threading bietet eine Reihe von Synchronisationsprimitiven zur Koordinierung gleichzeitiger Operationen. Dies ist besonders notwendig aufgrund der gemeinsamen Zustandsnatur des Threadings. Im Gegensatz dazu teilen Interpreter keine Zustände. Datenteilung ist auf die Fähigkeit der Laufzeit zur Bereitstellung von teilbaren Objekten beschränkt, was die Notwendigkeit expliziter Synchronisation entfällt. Wenn in Zukunft eine Art optionaler Unterstützung für gemeinsam genutzte Zustände zu CPythons Interpretern hinzugefügt wird, kann dieselbe Anstrengung Synchronisationsprimitive einführen, um diesem Bedarf gerecht zu werden.

CSP-Bibliothek

Ein Modul csp wäre kein großer Schritt weg von der Funktionalität, die dieser PEP bietet. Das Hinzufügen eines solchen Moduls liegt jedoch außerhalb der minimalistischen Ziele dieses Vorschlags.

Syntaktische Unterstützung

Die Sprache Go bietet ein Nebenläufigkeitsmodell, das auf CSP basiert, daher ähnelt es dem Nebenläufigkeitsmodell, das mehrere Interpreter unterstützen. Allerdings bietet Go auch syntaktische Unterstützung sowie mehrere integrierte Nebenläufigkeitsprimitive, um Nebenläufigkeit zu einer erstklassigen Funktion zu machen. Denkbar wäre, dass eine ähnliche syntaktische (und integrierte) Unterstützung in Python mithilfe von Interpretern hinzugefügt werden könnte. Dies liegt jedoch *weit* außerhalb des Rahmens dieser PEP!

Multiprocessing

Das Modul multiprocessing könnte Interpreter auf die gleiche Weise unterstützen, wie es Threads und Prozesse unterstützt. Tatsächlich hat der Maintainer des Moduls, Davin Potts, angegeben, dass dies eine angemessene Funktionsanforderung ist. Es liegt jedoch außerhalb des engen Umfangs dieser PEP.

C-Erweiterung Opt-in/Opt-out

Durch die Verwendung des PyModuleDef_Slot, der von PEP 489 eingeführt wurde, könnten wir leicht einen Mechanismus hinzufügen, mit dem C-Erweiterungsmodule die Unterstützung für mehrere Interpreter ablehnen können. Dann müsste die Importmaschinerie beim Betrieb in einem Subinterpreter das Modul auf Unterstützung prüfen. Es würde einen ImportError auslösen, wenn es nicht unterstützt wird.

Alternativ könnten wir die Unterstützung für die Einbeziehung mehrerer Interpreter unterstützen. Dies würde jedoch wahrscheinlich mehr Module (unnötigerweise) ausschließen als der Opt-out-Ansatz. Beachten Sie auch, dass PEP 489 definiert hat, dass die Verwendung der PEP-Mechanismen einer Erweiterung die Unterstützung für mehrere Interpreter impliziert.

Der Umfang der Hinzufügung des ModuleDef-Slots und der Anpassung der Importmaschinerie ist nicht trivial, könnte sich aber lohnen. Es hängt alles davon ab, wie viele Erweiterungsmodule unter Subinterpretern brechen. Da wir durch mod_wsgi nur relativ wenige Fälle kennen, können wir dies für später aufschieben.

Kanäle vergiften

CSP hat das Konzept der Vergiftung eines Kanals. Sobald ein Kanal vergiftet ist, würde jeder send()- oder recv()-Aufruf darauf eine spezielle Ausnahme auslösen, die effektiv die Ausführung im Interpreter beendet, der versucht hat, den vergifteten Kanal zu verwenden.

Dies könnte durch die Hinzufügung einer Methode poison() zu beiden Enden des Kanals erreicht werden. Die Methode close() kann auf diese Weise (größtenteils) verwendet werden, aber diese Semantik ist relativ spezialisiert und kann warten.

__main__ zurücksetzen

Wie vorgeschlagen, wird jeder Aufruf von Interpreter.exec() im Namensraum des bestehenden Moduls __main__ des Interpreters ausgeführt. Das bedeutet, dass die Daten dort zwischen interp.exec()-Aufrufen persistent bleiben. Manchmal ist dies nicht erwünscht und man möchte in einem frischen __main__ ausführen. Außerdem möchte man dort nicht unbedingt Objekte leaken, die man nicht mehr verwendet.

Beachten Sie, dass das Folgende nicht richtig funktioniert, da es zu viel löschen wird (z.B. __name__ und die anderen "__dunder__"-Attribute).

interp.exec('globals().clear()')

Mögliche Lösungen beinhalten:

• ein Argument create(), um __main__ nach jedem interp.exec()-Aufruf zurückzusetzen.
• ein Flag Interpreter.reset_main, um nachträglich das Aktivieren oder Deaktivieren zu unterstützen.
• eine Methode Interpreter.reset_main(), um bei Bedarf zu aktivieren.
• importlib.util.reset_globals() [reset_globals].

Beachten Sie auch, dass das Zurücksetzen von __main__ nichts am Zustand anderer Module ändert. Jede Lösung müsste also klarstellen, was zurückgesetzt wird. Denkbar wäre, dass wir einen Mechanismus erfinden, mit dem jedes (oder jedes) Modul zurückgesetzt werden könnte, im Gegensatz zu reload(), das das Modul nicht vor dem Laden leert.

Unabhängig davon hat das Zurücksetzen von __main__, da es der Ausführungsnamensraum des Interpreters ist, eine viel direktere Korrelation zu den Interpretern und ihrem dynamischen Zustand als das Zurücksetzen anderer Module. Ein allgemeinerer Modulrücksetzmechanismus mag daher unnötig sein.

Dies ist anfangs keine kritische Funktion. Sie kann später, wenn gewünscht, warten.

Den Zustand eines Interpreters zurücksetzen

Es wäre praktisch, einen bestehenden Subinterpreter wiederzuverwenden, anstatt einen neuen zu starten. Da ein Interpreter deutlich mehr Zustand hat als nur das Modul __main__, ist es nicht so einfach, einen Interpreter wieder in einen makellosen/frischen Zustand zu versetzen. Tatsächlich *könnten* Teile des Zustands nicht aus Python-Code zurückgesetzt werden.

Eine mögliche Lösung ist die Hinzufügung einer Methode Interpreter.reset(). Diese würde den Interpreter in den Zustand zurückversetzen, in dem er sich befand, als er neu erstellt wurde. Wenn sie auf einen laufenden Interpreter angewendet wird, schlägt sie fehl (daher kann der Hauptinterpreter niemals zurückgesetzt werden). Dies wäre wahrscheinlich effizienter als die Erstellung eines neuen Interpreters, obwohl dies von den später vorgenommenen Optimierungen der Interpretererstellung abhängt.

Während dies potenziell Funktionalität bietet, die sonst nicht aus Python-Code verfügbar ist, ist es keine grundlegende Funktionalität. Im Sinne des Minimalismus kann dies also warten. Ungeachtet dessen bezweifle ich, dass seine Hinzufügung nach PEP kontrovers wäre.

Den Zustand eines vorhandenen Interpreters kopieren

In verwandter Weise könnte es nützlich sein, die Erstellung eines neuen Interpreters basierend auf einem bestehenden zu unterstützen, z.B. Interpreter.copy(). Dies knüpft an die Idee an, dass ein Schnappschuss des Speichers eines Interpreters erstellt werden könnte, was das Starten von CPython oder die Erstellung neuer Interpreter im Allgemeinen beschleunigen würde. Derselbe Mechanismus könnte für einen hypothetischen Interpreter.reset() verwendet werden, wie zuvor beschrieben.

Teilbare File Descriptors und Sockets

Da Dateideskriptoren und Sockets prozessweite Ressourcen sind, ist ihre Teilbarkeit eine sinnvolle Idee. Sie wären ein guter Kandidat für die erste Anstrengung zur Erweiterung der unterstützten teilbaren Typen. Sie sind für die anfängliche API nicht zwingend erforderlich.

Integration mit async

Laut Antoine Pitrou [async].

Has any thought been given to how FIFOs could integrate with async
code driven by an event loop (e.g. asyncio)?  I think the model of
executing several asyncio (or Tornado) applications each in their
own subinterpreter may prove quite interesting to reconcile multi-
core concurrency with ease of programming.  That would require the
FIFOs to be able to synchronize on something an event loop can wait
on (probably a file descriptor?).

Die grundlegende Funktionalität der Unterstützung mehrerer Interpreter hängt nicht von async ab und kann später hinzugefügt werden.

Eine mögliche Lösung ist die Bereitstellung von Async-Implementierungen der blockierenden Kanalmethoden (recv() und send()).

Alternativ könnten "readiness callbacks" verwendet werden, um die Verwendung in asynchronen Szenarien zu vereinfachen. Dies würde bedeuten, einen optionalen Parameter callback (kw-only) zu den Methoden recv_nowait() und send_nowait() des Kanals hinzuzufügen. Der Callback würde aufgerufen, sobald das Objekt gesendet oder empfangen wurde (jeweils).

(Beachten Sie, dass das Puffern von Kanälen die Bedeutung von Readiness Callbacks verringert.)

Unterstützung für Iteration

Die Unterstützung für die Iteration über RecvChannel (über __iter__() oder _next__()) könnte nützlich sein. Eine triviale Implementierung würde die Methode recv() verwenden, ähnlich wie Dateien iterieren. Da dies keine grundlegende Fähigkeit ist und ein einfaches Analogon hat, kann die Unterstützung für die Iteration später warten.

Kanal-Kontextmanager

Die Unterstützung für Kontextmanager auf RecvChannel und SendChannel könnte hilfreich sein. Die Implementierung wäre einfach und würde einen Aufruf von close() (oder vielleicht release()) umschließen, ähnlich wie bei Dateien. Wie bei der Iteration kann dies warten.

Pipes und Queues

Mit dem vorgeschlagenen Mechanismus zur Objektübergabe von "os.pipe()" sind andere ähnliche grundlegende Typen nicht unbedingt erforderlich, um die minimale nützliche Funktionalität mehrerer Interpreter zu erreichen. Solche Typen umfassen Pipes (wie unbuffered Kanäle, aber Eins-zu-Eins) und Queues (wie Kanäle, aber generischer). Siehe unten in Abgelehnte Ideen für weitere Informationen.

Auch wenn diese Typen nicht Teil dieses Vorschlags sind, können sie im Kontext der Nebenläufigkeit dennoch nützlich sein. Ihre spätere Hinzufügung ist völlig vernünftig. Sie könnten trivial als Wrapper um Kanäle implementiert werden. Alternativ könnten sie aus Effizienzgründen auf derselben niedrigen Ebene wie Kanäle implementiert werden.

Ein Lock von send() zurückgeben

Beim Senden eines Objekts über einen Kanal wissen Sie nicht, wann das Objekt am anderen Ende empfangen wird. Eine Möglichkeit, dies zu umgehen, besteht darin, einen gesperrten threading.Lock von SendChannel.send() zurückzugeben, der entsperrt wird, sobald das Objekt empfangen wurde.

Alternativ bieten die vorgeschlagenen SendChannel.send() (blockierend) und SendChannel.send_nowait() eine explizite Unterscheidung, die Benutzer wahrscheinlich weniger verwirrt.

Beachten Sie, dass die Rückgabe eines Locks für gepufferte Kanäle (d.h. Queues) relevant wäre. Für unbuffered Kanäle ist dies kein Problem.

Priorisierung in Kanälen unterstützen

Ein einfaches Beispiel ist queue.PriorityQueue in der Standardbibliothek.

Unterstützung für das Erben von Einstellungen (und mehr?)

Es könnte für Benutzer nützlich sein, beim Erstellen eines neuen Interpreters angeben zu können, dass sie einige Dinge vom neuen Interpreter "erben" möchten. Der Mechanismus könnte eine strikte Kopie oder eine Copy-on-Write sein. Das motivierende Beispiel ist das Warnungsmodul (z.B. Kopieren der Filter).

Die Funktion ist weder kritisch noch weit verbreitet, daher kann sie warten, bis Interesse besteht. Insbesondere werden beide vorgeschlagenen Lösungen erhebliche Arbeit erfordern, insbesondere bei komplexen Objekten und vor allem bei veränderlichen Containern veränderlicher komplexer Objekte.

Ausnahmen teilbar machen

Ausnahmen werden aus run()-Aufrufen propagiert, daher ist es kein großer Schritt, sie teilbar zu machen. Wie an anderer Stelle erwähnt, ist dies jedoch nicht essentiell oder (besonders häufig), daher können wir damit warten.

Alles durch Serialisierung teilbar machen

Wir könnten Pickle (oder Marshal) verwenden, um alles zu serialisieren und somit teilbar zu machen. Dies ist potenziell ineffizient, aber es könnte letztendlich eine Frage der Bequemlichkeit sein. Wir können es später hinzufügen, aber der Versuch, es später zu entfernen, wäre deutlich schmerzhafter.

RunFailedError.__cause__ verzögert machen

Eine nicht abgefangene Ausnahme in einem Subinterpreter (von interp.exec()) wird in den aufrufenden Interpreter kopiert und als __cause__ auf einem RunFailedError gesetzt, der dann ausgelöst wird. Dieses Kopieren beinhaltet eine Art Deserialisierung im aufrufenden Interpreter, was teuer sein kann (z.B. aufgrund von Imports) und nicht immer notwendig ist.

Daher könnte es nützlich sein, einen ExceptionProxy-Typ zu verwenden, um die serialisierte Ausnahme zu umschließen und sie erst zu deserialisieren, wenn sie benötigt wird. Dies könnte über ExceptionProxy__getattribute__() oder vielleicht über RunFailedError.resolve() geschehen (was die deserialisierte Ausnahme auslösen und RunFailedError.__cause__ auf die Ausnahme setzen würde).

Es könnte auch sinnvoll sein, dass RunFailedError.__cause__ ein Deskriptor ist, der die verzögerte Deserialisierung (und das Setzen von __cause__) auf der Instanz von RunFailedError durchführt.

Einen Wert von interp.exec() zurückgeben

Derzeit gibt interp.exec() immer None zurück. Eine Idee ist, den Rückgabewert dessen zurückzugeben, was der Subinterpreter ausgeführt hat. Vorerst macht das jedoch keinen Sinn. Das Einzige, was ausgeführt werden kann, ist ein Code-String (d.h. ein Skript). Dies entspricht PyRun_StringFlags(), exec() oder einem Modulkörper. Keine dieser Funktionen "gibt" etwas zurück. Wir können dies noch einmal überprüfen, sobald interp.exec() Funktionen usw. unterstützt.

Ein teilbares Synchronisationsprimitive hinzufügen

Dies wäre _threading.Lock (oder etwas Ähnliches), bei dem Interpreter tatsächlich den zugrunde liegenden Mutex teilen würden. Die Hauptsorge ist, dass Locks und isolierte Interpreter möglicherweise nicht gut zusammenpassen (wie in Go gelernt).

Wir können dies später hinzufügen, wenn es sich als wünschenswert erweist, ohne viel Schwierigkeiten.

SystemExit und KeyboardInterrupt unterschiedlich weitergeben

Die Ausnahmetypen, die von BaseException (außer Exception) erben, werden normalerweise speziell behandelt. Diese Typen sind: KeyboardInterrupt, SystemExit und GeneratorExit. Es könnte sinnvoll sein, sie speziell zu behandeln, wenn es um die Weitergabe von interp.exec() geht. Hier sind einige Optionen:

* propagate like normal via RunFailedError
* do not propagate (handle them somehow in the subinterpreter)
* propagate them directly (avoid RunFailedError)
* propagate them directly (set RunFailedError as __cause__)

Wir werden uns nicht darum kümmern, sie anders zu behandeln. Threads ignorieren bereits SystemExit, also werden wir vorerst diesem Muster folgen.

Ein explizites release() und close() zu Channel-End-Klassen hinzufügen

Es kann praktisch sein, eine explizite Möglichkeit zu haben, einen Kanal für weitere globale Nutzung zu schließen. Ebenso könnte es nützlich sein, eine explizite Möglichkeit zu haben, ein Ende des Kanals relativ zum aktuellen Interpreter freizugeben. Unter anderem ist ein solcher Mechanismus nützlich, um den Gesamtstatus zwischen Interpretern zu kommunizieren, ohne den zusätzlichen Boilerplate-Code, der das direkte Übergeben von Objekten über einen Kanal erfordern würde.

Die Herausforderung besteht darin, die automatische Freigabe/Schließung korrekt zu gestalten, ohne sie schwer verständlich zu machen. Dies gilt insbesondere bei einem nicht leeren Kanal. Wir sollten vorerst ohne Freigabe/Schließung auskommen.

SendChannel.send_buffer() hinzufügen

Diese Methode würde das Senden eines Objekts über einen Kanal ohne Kopie ermöglichen, wenn es das PEP 3118-Pufferprotokoll unterstützt (z.B. memoryview).

Die Unterstützung dafür ist für Kanäle nicht grundlegend und kann später ohne größere Störung hinzugefügt werden.

Automatisch in einem Thread ausführen

Der PEP schlägt eine klare Trennung zwischen Subinterpretern und Threads vor: Wenn Sie in einem Thread ausführen möchten, müssen Sie den Thread selbst erstellen und interp.exec() darin aufrufen. Es könnte jedoch praktisch sein, wenn interp.exec() dies für Sie tun könnte, was weniger Boilerplate bedeuten würde.

Darüber hinaus gehen wir davon aus, dass Benutzer viel öfter in einem Thread ausführen möchten als nicht. Daher wäre es sinnvoll, dies zum Standardverhalten zu machen. Wir würden einen kw-only Parameter "threaded" (Standard True) zu interp.exec() hinzufügen, um den Vorgang im aktuellen Thread zu ermöglichen.

Explizite Kanalassoziation

Interpreter werden bei recv()- und send()-Aufrufen implizit mit Kanalenden assoziiert. Sie werden bei release()-Aufrufen de-assoziiert. Die Alternative wären explizite Methoden. Es wären entweder Methoden add_channel() und remove_channel() für Interpreter-Objekte oder etwas Ähnliches für Kanalobjekte.

In der Praxis sollte dieses Verwaltungsniveau für Benutzer nicht notwendig sein. Das Hinzufügen von expliziterer Unterstützung würde die API nur unnötig aufblähen.

Eine API basierend auf Pipes hinzufügen

Eine Pipe wäre ein Simplex-FIFO zwischen genau zwei Interpretern. Für die meisten Anwendungsfälle wäre dies ausreichend. Es könnte potenziell auch die Implementierung vereinfachen. Es ist jedoch kein großer Schritt, einen Many-to-Many-Simplex-FIFO über Kanäle zu unterstützen. Auch bei Pipes wird die API etwas komplizierter, da die Pipes benannt werden müssen.

Eine API basierend auf Queues hinzufügen

Queues und gepufferte Kanäle sind fast dasselbe. Der Hauptunterschied besteht darin, dass Kanäle eine stärkere Beziehung zum Kontext (d.h. dem assoziierten Interpreter) haben.

Der Name "Channel" wurde anstelle von "Queue" verwendet, um Verwechslungen mit der Standardbibliothek queue.Queue zu vermeiden.

„enumerate“

Die Funktion list_all() liefert die Liste aller Interpreter. Im Threading-Modul, das die vorgeschlagene API teilweise inspiriert hat, heißt die Funktion enumerate(). Der Name ist hier anders, um Python-Benutzer, die nicht mit der Threading-API vertraut sind, nicht zu verwirren. Für sie ist "enumerate" eher unklar, während "list_all" klar ist.

Alternative Lösungen zur Verhinderung von Ausnahmenlecks zwischen Interpretern

In Funktionsaufrufen propagieren nicht abgefangene Ausnahmen in den aufrufenden Frame. Derselbe Ansatz könnte mit interp.exec() verfolgt werden. Dies würde jedoch bedeuten, dass Ausnameobjekte die Inter-Interpreter-Grenze überschreiten. Ebenso könnten die Frames im Traceback überschreiten.

Das mag derzeit kein Problem sein, wäre aber ein Problem, sobald Interpreter eine bessere Isolation in Bezug auf die Speicherverwaltung erhalten (was notwendig ist, um die gemeinsame Nutzung des GIL zwischen Interpretern zu beenden). Wir haben die Semantik der Ausnahmenausbreitung gelöst, indem wir stattdessen eine RunFailedError auslösen, bei der __cause__ einen sicheren Proxy für die ursprüngliche Ausnahme und den Traceback umschließt.

Abgelehnte mögliche Lösungen:

• die Ausnahme und den Traceback im ursprünglichen Interpreter reproduzieren und auslösen.
• eine Unterklasse von RunFailedError auslösen, die die ursprüngliche Ausnahme und den Traceback proxy-isiert.
• RuntimeError statt RunFailedError auslösen.
• an der Grenze konvertieren (a la subprocess.CalledProcessError) (erfordert eine cross-Interpreter-Darstellung).
• Anpassung über Interpreter.excepthook unterstützen (erfordert eine cross-Interpreter-Darstellung).
• an der Grenze in einen Proxy einschließen (einschließlich Unterstützung für etwas wie err.raise(), um den Traceback zu propagieren).
• die Ausnahme (oder ihren Proxy) von interp.exec() zurückgeben, anstatt sie auszulösen.
• ein Ergebnisobjekt zurückgeben (wie subprocess es tut) [result-object] (unnötige Komplexität?).
• die Ausnahme verwerfen und den Benutzern erwarten, dass sie nicht abgefangene Ausnahmen explizit in dem Skript behandeln, das sie an interp.exec() übergeben (sie können Fehlerinformationen über Kanäle nach außen übergeben); mit Threads muss man etwas Ähnliches tun.

Jeden neuen Interpreter immer mit seinem eigenen Thread verbinden

Wie in der C-API implementiert, ist ein Interpreter nicht inhärent an einen Thread gebunden. Darüber hinaus läuft er in jedem vorhandenen Thread, egal ob er von Python erstellt wurde oder nicht. Sie müssen nur zuerst einen seiner Thread-Zustände (PyThreadState) in dem Thread aktivieren. Das bedeutet, dass derselbe Thread mehr als einen Interpreter ausführen kann (wenn auch offensichtlich nicht gleichzeitig).

Das vorgeschlagene Modul behält dieses Verhalten bei. Interpreter sind nicht an Threads gebunden. Nur Aufrufe von Interpreter.exec() sind es. Ein Hauptziel dieser PEP ist es jedoch, ein menschzentrierteres Nebenläufigkeitsmodell bereitzustellen. Mit diesem im Hinterkopf könnte das Modul aus konzeptioneller Sicht einfacher zu verstehen sein, wenn jeder Interpreter mit einem eigenen Thread assoziiert wäre.

Das würde bedeuten, dass interpreters.create() einen neuen Thread erstellt und Interpreter.exec() nur in diesem Thread ausgeführt wird (und nichts anderes). Der Vorteil ist, dass Benutzer Interpreter.exec()-Aufrufe nicht in einen neuen threading.Thread einwickeln müssten. Sie wären auch nicht in der Lage, versehentlich den aktuellen Interpreter (im aktuellen Thread) anzuhalten, während ihr Interpreter ausgeführt wird.

Die Idee wird verworfen, da der Vorteil gering und die Kosten hoch sind. Der Unterschied zur Funktionalität in der C-API wäre potenziell verwirrend. Die implizite Erstellung von Threads ist magisch. Die frühe Erstellung von Threads ist potenziell verschwenderisch. Die Unfähigkeit, beliebige Interpreter in einem vorhandenen Thread auszuführen, würde einige gültige Anwendungsfälle verhindern und Benutzer frustrieren. Die Bindung von Interpretern an Threads würde zusätzliche Laufzeitmodifikationen erfordern. Sie würde auch die Implementierung des Moduls übermäßig komplizieren. Schließlich könnte sie das Modul nicht einmal einfacher zu verstehen machen.

Interpreter nur bei Verwendung verbinden

Interpreter nur dann mit Kanalenden assoziieren, wenn recv(), send() usw. aufgerufen werden.

Dies ist potenziell verwirrend und kann auch zu unerwarteten Wettläufen führen, bei denen ein Kanal automatisch geschlossen wird, bevor er im ursprünglichen (erstellenden) Interpreter verwendet werden kann.

Mehrere gleichzeitige Aufrufe von Interpreter.exec() zulassen

Dies wäre insbesondere dann sinnvoll, wenn Interpreter.exec() neue Threads für Sie verwalten würde (was wir abgelehnt haben). Im Wesentlichen würde jeder Aufruf unabhängig ausgeführt, was aus einer engen technischen Perspektive meist in Ordnung wäre, da jeder Interpreter mehrere Threads haben kann.

Das Problem ist, dass der Interpreter nur ein einziges __main__-Modul hat und gleichzeitige Interpreter.exec()-Aufrufe __main__ teilen müssten oder wir müssten einen neuen Mechanismus erfinden. Keines davon wäre einfach genug, um sich lohnen zu würde.

Eine „reraise“-Methode zu RunFailedError hinzufügen

Während __cause__ bei RunFailedError gesetzt ist und zu einer nützlicheren Traceback beiträgt, ist es bei der Behandlung des ursprünglichen Fehlers weniger hilfreich. Um dies zu erleichtern, könnten wir RunFailedError.reraise() hinzufügen. Diese Methode würde das folgende Muster ermöglichen

try:
    try:
        interp.exec(script)
    except RunFailedError as exc:
        exc.reraise()
except MyException:
    ...

Dies würde noch einfacher gemacht, wenn es ein __reraise__-Protokoll gäbe.

All das gesagt, ist dies völlig unnötig. Die Verwendung von __cause__ ist gut genug

try:
    try:
        interp.exec(script)
    except RunFailedError as exc:
        raise exc.__cause__
except MyException:
    ...

Beachten Sie, dass dies in extremen Fällen etwas zusätzlichen Boilerplate-Code erfordern kann

try:
    try:
        interp.exec(script)
    except RunFailedError as exc:
        if exc.__cause__ is not None:
            raise exc.__cause__
        raise  # re-raise
except MyException:
    ...