Zusammenfassung

Manchmal, in speziellen Fällen, ist es erwünscht, dass Code Informationen über die Aufrufkette an die Aufgerufenen weitergeben kann, ohne die Informationen explizit als Argumente an jede Funktion in der Aufrufkette übergeben zu müssen. Dieser Vorschlag beschreibt ein Konstrukt, das es Code ermöglicht, explizit in einen Kontext ein- und auszutreten, in dem eine bestimmte Kontextvariable einen gegebenen Wert zugewiesen hat. Dies ist eine moderne Alternative zu einigen Verwendungen von Dingen wie globalen Variablen im traditionellen Single-Threaded (oder Thread-unsicheren) Code und von Thread-lokalem Speicher im traditionellen *Concurrency-unsicheren* Code (Single- oder Multi-Threaded). Insbesondere kann der vorgeschlagene Mechanismus auch mit moderneren nebenläufigen Ausführungsmechanismen wie asynchron ausgeführten Coroutinen verwendet werden, ohne dass die nebenläufig ausgeführten Aufrufkette die Kontexte des jeweils anderen beeinträchtigen.

Die „Aufrufkette“ kann aus normalen Funktionen, await-fähigen Coroutinen oder Generatoren bestehen. Die Semantik des Geltungsbereichs von Kontextvariablen ist in allen Fällen gleichwertig und ermöglicht es, Code frei in *Unterroutinen* (was hier Funktionen, Sub-Generatoren oder Sub-Coroutinen bezeichnet) zu refaktorieren, ohne die Semantik von Kontextvariablen zu beeinträchtigen. Hinsichtlich der Implementierung zielt dieser Vorschlag auf Einfachheit und minimale Änderungen am CPython-Interpreter und anderen Python-Interpretern ab.

Begründung

Betrachten Sie eine moderne Python-*Aufrufkette* (oder Aufrufbaum), die in diesem Vorschlag jede verkettete (verschachtelte) Ausführung von *Unterroutinen* bezeichnet, unter Verwendung beliebiger Kombinationen von normalen Funktionsaufrufen oder Ausdrücken, die await oder yield from verwenden. In einigen Fällen kann die Übergabe notwendiger *Informationen* über die Aufrufkette als Argumente die erforderlichen Funktionssignaturen erheblich verkomplizieren oder ist praktisch unmöglich zu erreichen. In diesen Fällen kann man nach einem anderen Ort suchen, um diese Informationen zu speichern. Betrachten wir einige historische Beispiele.

Die naheliegendste Option ist die Zuweisung des Werts zu einer globalen Variable oder ähnlichem, auf die der Code in der Aufrufkette zugreifen kann. Dies macht den Code jedoch sofort Thread-unsicher, da bei mehreren Threads alle Threads der gleichen globalen Variablen zugewiesen werden und ein anderer Thread jederzeit in der Aufrufkette eingreifen kann. Früher oder später wird wahrscheinlich jemand einen Grund finden, denselben Code in parallelen Threads auszuführen.

Eine etwas weniger naive Option ist es, die Informationen als pro-Thread-Informationen in Thread-lokalem Speicher zu speichern, wobei jeder Thread seine eigene „Kopie“ der Variablen hat, in die andere Threads nicht eingreifen können. Obwohl nicht ideal, war dies in vielen Fällen die beste Lösung. Dank Generatoren und Coroutinen kann die Ausführung der Aufrufkette unterbrochen und fortgesetzt werden, was es Code in anderen Kontexten ermöglicht, nebenläufig ausgeführt zu werden. Daher ist die Verwendung von Thread-lokalem Speicher *Concurrency-unsicher*, da andere Aufrufkette in anderen Kontexten die Thread-lokale Variable beeinträchtigen können.

Beachten Sie, dass in den oben genannten beiden historischen Ansätzen die gespeicherten Informationen den *breitesten* verfügbaren Geltungsbereich haben, ohne Probleme zu verursachen. Für eine dritte Lösung auf demselben Weg würde man zuerst ein Äquivalent eines „Threads“ für asynchrone Ausführung und Nebenläufigkeit definieren. Dies könnte als die größte Menge an Code und verschachtelten Aufrufen betrachtet werden, die garantiert sequenziell ohne Mehrdeutigkeit in der Ausführungsreihenfolge ausgeführt wird. Dies könnte als Concurrency-lokaler oder Task-lokaler Speicher bezeichnet werden. In dieser Bedeutung von „Task“ gibt es keine Mehrdeutigkeit in der Reihenfolge der Ausführung des Codes innerhalb eines Tasks. (Dieses Konzept eines Tasks ist nahe verwandt mit einem Task in asyncio, aber nicht exakt.) In solchen Concurrency-lokalen ist es möglich, Informationen über die Aufrufkette an die Aufgerufenen weiterzugeben, ohne dass ein anderer Code-Pfad den Wert im Hintergrund beeinträchtigt.

Gemeinsam für die obigen Ansätze ist, dass sie tatsächlich Variablen mit einem breiten, aber gerade engen genug Geltungsbereich verwenden. Thread-lokale Variablen könnten auch als Thread-weite Globale bezeichnet werden – im Single-Threaded-Code sind sie tatsächlich wirklich global. Und Task-lokale Variablen könnten als Task-weite Globale bezeichnet werden, da Tasks sehr groß sein können.

Das Problem hierbei ist, dass weder globale Variablen, Thread-lokale noch Task-lokale für diesen Zweck der Übergabe von Informationen des Ausführungskontexts über die Aufrufkette gedacht sind. Anstelle des breitestmöglichen Geltungsbereichs von Variablen sollte der Geltungsbereich der Variablen vom Programmierer, typischerweise einer Bibliothek, gesteuert werden, um den gewünschten Geltungsbereich zu haben – nicht breiter. Mit anderen Worten, Task-lokale Variablen (und Globale und Thread-lokale) haben nichts mit der Art der kontextgebundenen Informationsweitergabe zu tun, die dieser Vorschlag ermöglichen soll, auch wenn Task-lokale verwendet werden können, um die gewünschte Semantik zu emulieren. Daher beschreibt dieser Vorschlag im Folgenden die Semantik und die Umrisse einer Implementierung für *kontextlokale Variablen* (oder Kontextvariablen, contextvars). Tatsächlich kann ein asynchroner Framework als Nebeneffekt dieses PEPs die vorgeschlagene Funktion verwenden, um Task-lokale Variablen zu implementieren.

Vorschlag

Da die vorgeschlagene Semantik keine direkte Erweiterung von etwas bereits in Python Verfügbarem ist, wird dieser Vorschlag zunächst in Bezug auf Semantik und API auf einer ziemlich hohen Ebene beschrieben. Insbesondere werden Python with-Anweisungen stark in der Beschreibung verwendet, da sie gut zur vorgeschlagenen Semantik passen. Die zugrunde liegenden __enter__- und __exit__-Methoden entsprechen jedoch Funktionen in der schnelleren (C) API auf niedrigerer Ebene. Zur Klarheit dieses Dokuments werden die Funktionen auf niedrigerer Ebene in der Definition der Semantik nicht explizit benannt. Nach der Beschreibung der Semantik und der High-Level-API wird die Implementierung beschrieben, die auf eine niedrigere Ebene geht.

cvar = contextvars.Var(default="the default value",
                       description="example context variable")

assert cvar.value == "the default value"  # default still applies

# In code examples, all ``assert`` statements should
# succeed according to the proposed semantics.

with cvar.assign(new_value):
    assert cvar.value is new_value
    # Any code here, or down the call chain from here, sees:
    #     cvar.value is new_value
    # unless another value has been assigned in a
    # nested context
    assert cvar.value is new_value
# the assignment of ``cvar`` to ``new_value`` is no longer visible
assert cvar.value == "the default value"

assert cvar.value == "the default value"
with cvar.assign("outer"):
    assert cvar.value == "outer"
    with cvar.assign("inner"):
        assert cvar.value == "inner"
    assert cvar.value == "outer"
assert cvar.value == "the default value"

cvar1 = contextvars.Var()
cvar2 = contextvars.Var()

assert cvar1.value is None # default is None by default
assert cvar2.value is None

with cvar1.assign(value1):
    assert cvar1.value is value1
    assert cvar2.value is None
    with cvar2.assign(value2):
        assert cvar1.value is value1
        assert cvar2.value is value2
    assert cvar1.value is value1
    assert cvar2.value is None
assert cvar1.value is None
assert cvar2.value is None

with cvar1.assign(value1), cvar2.assign(value2):
    assert cvar1.value is value1
    assert cvar2.value is value2

assi = cvar.assign(new_value)
def apply():
    assi.__enter__()
assert cvar.value == "the default value"
apply()
assert cvar.value is new_value
assi.__exit__()
assert cvar.value == "the default value"

assi = cvar.assign(new_value)
async def apply():
    assi.__enter__()
assert cvar.value == "the default value"
await apply()
assert cvar.value is new_value
assi.__exit__()
assert cvar.value == "the default value"

def apply():
    yield
    assi.__enter__()

def genfunc():
    with cvar.assign(new_value):
        assert cvar.value is new_value
        yield
        assert cvar.value is new_value
g = genfunc()
next(g)
assert cvar.value == "the default value"
with cvar.assign(another_value):
    next(g)

def genfunc():
    assert cvar.value is value2
    yield
    assert cvar.value is value1
    yield
    with cvar.assign(value3):
        assert cvar.value is value3

with cvar.assign(value1):
    g = genfunc()
    with cvar.assign(value2):
        next(g)
    next(g)
    next(g)
    assert cvar.value is value1

assi = cvar.assign(new_value)
def genfunc():
    yield
    assi.__enter__():
    yield

g = genfunc()
assert cvar.value == "the default value"
next(g)
assert cvar.value == "the default value"
next(g)  # assi.__enter__() is called here
assert cvar.value == "the default value"
next(g)
assert cvar.value is new_value
assi.__exit__()

@contextvars.leaking_yields
def genfunc():
    assert cvar.value == "outer"
    with cvar.assign("inner"):
        yield
        assert cvar.value == "inner"
    assert cvar.value == "outer"

g = genfunc():
with cvar.assign("outer"):
    assert cvar.value == "outer"
    next(g)
    assert cvar.value == "inner"
    next(g)
    assert cvar.value == "outer"

assert cvar1.value is None # default
assert cvar2.value is None # default
assi1 = cvar1.assign(value1)
assi2 = cvar1.assign(value2)
with contextvars.capture() as delta:
    assi1.__enter__()
    with cvar2.assign("not captured"):
        assert cvar2.value is "not captured"
    assi2.__enter__()
assert cvar1.value is value2
delta.revert()
assert cvar1.value is None
assert cvar2.value is None
...
with cvar1.assign(1), cvar2.assign(2):
    delta.reapply()
    assert cvar1.value is value2
    assert cvar2.value == 2

with context_vars.clean_context():
    # here, all context vars start off with their default values
# here, the state is back to what it was before the with block.

cvar1 = contextvars.Var()
cvar2 = contextvars.Var()
# stack: []
assert cvar1.value is None
assert cvar2.value is None

with cvar1.assign("outer"):
    # stack: [Assignment(cvar1, "outer")]
    assert cvar1.value == "outer"

    with cvar1.assign("inner"):
        # stack: [Assignment(cvar1, "outer"),
        #         Assignment(cvar1, "inner")]
        assert cvar1.value == "inner"

        with cvar2.assign("hello"):
            # stack: [Assignment(cvar1, "outer"),
            #         Assignment(cvar1, "inner"),
            #         Assignment(cvar2, "hello")]
            assert cvar2.value == "hello"

        # stack: [Assignment(cvar1, "outer"),
        #         Assignment(cvar1, "inner")]
        assert cvar1.value == "inner"
        assert cvar2.value is None

    # stack: [Assignment(cvar1, "outer")]
    assert cvar1.value == "outer"

# stack: []
assert cvar1.value is None
assert cvar2.value is None

def send(self, value):
    if self.gi_contextvars is LEAK:
        # If decorated with contextvars.leaking_yields.
        # Nothing needs to be done to leak context through yields :)
        return self._old_send(value)
    try:
        with contextvars.capture() as delta:
            if self.gi_contextvars:
                # non-zero captured content from previous iteration
                self.gi_contextvars.reapply()
            ret = self._old_send(value)
    except Exception:
        raise  # back to the calling frame (e.g. StopIteration)
    else:
        # suspending, revert context changes but save them for later
        delta.revert()
        self.gi_contextvars = delta
    return ret

Abwärtskompatibilität

Es gibt keine *direkten* Abwärtskompatibilitätsprobleme, da eine völlig neue Funktion vorgeschlagen wird.

Allerdings müssen verschiedene traditionelle Verwendungen von Thread-lokalem Speicher einen reibungslosen Übergang zu contextvars erfahren, damit sie Concurrency-sicher sein können. Es gibt verschiedene Ansätze dafür, einschließlich der Emulation von Task-lokalem Speicher mit ein wenig Hilfe von asynchronen Frameworks. Eine vollständig allgemeine Implementierung kann nicht bereitgestellt werden, da die gewünschte Semantik vom Design des Frameworks abhängen kann.

Eine andere Möglichkeit, mit dem Übergang umzugehen, besteht darin, dass Code zuerst nach einem mit contextvars erstellten Kontext sucht. Wenn dies fehlschlägt, weil kein neuer Kontext gesetzt wurde oder weil der Code auf einer älteren Python-Version läuft, wird auf Thread-lokalen Speicher zurückgegriffen.

Offene Fragen

Abgelehnte Ideen

Danksagungen

Wird noch hinzugefügt.

Referenzen

Wird noch hinzugefügt.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.