Zusammenfassung

Python erlaubt den Anweisungen with und async with, mehrere Kontextmanager in einer einzigen Anweisung zu handhaben, solange sie alle synchron bzw. asynchron sind. Beim Mischen von synchronen und asynchronen Kontextmanagern müssen Entwickler tief verschachtelte Anweisungen verwenden oder riskante Workarounds wie die übermäßige Nutzung von AsyncExitStack nutzen.

Wir schlagen daher vor, dass with-Anweisungen sowohl synchrone als auch asynchrone Kontextmanager in einer einzigen Anweisung akzeptieren, indem einzelne async-Kontextmanager mit dem Schlüsselwort async präfigiert werden.

Diese Änderung eliminiert unnötige Verschachtelung, verbessert die Lesbarkeit des Codes und erhöht die Ergonomie, ohne den async-Code weniger explizit zu machen.

Motivation

Moderne Python-Anwendungen müssen häufig mehrere Ressourcen erwerben, über eine Mischung aus synchronen und asynchronen Kontextmanagern. Während die reinen Sync- oder reinen Async-Fälle eine einzelne Anweisung mit mehreren Kontextmanagern zulassen, führt das Mischen der beiden zum „Staircase of Doom“ (Treppe des Verderbens).

async def process_data():
    async with acquire_lock() as lock:
        with temp_directory() as tmpdir:
            async with connect_to_db(cache=tmpdir) as db:
                with open('config.json', encoding='utf-8') as f:
                    # We're now 16 spaces deep before any actual logic
                    config = json.load(f)
                    await db.execute(config['query'])
                    # ... more processing

Diese übermäßige Einrückung entmutigt die Verwendung von Kontextmanagern trotz ihrer wünschenswerten Semantik. Siehe den Abschnitt Abgelehnte Ideen für aktuelle Workarounds und Kommentare zu deren Nachteilen.

Mit diesem PEP könnte die Funktion stattdessen so geschrieben werden:

async def process_data():
    with (
        async acquire_lock() as lock,
        temp_directory() as tmpdir,
        async connect_to_db(cache=tmpdir) as db,
        open('config.json', encoding='utf-8') as f,
    ):
        config = json.load(f)
        await db.execute(config['query'])
        # ... more processing

Diese kompakte Alternative vermeidet, dass bei jedem Wechsel zwischen Sync- und Async-Kontextmanagern eine neue Einrückungsebene erzwungen wird. Gleichzeitig werden nur vorhandene Schlüsselwörter verwendet, wobei der asynchrone Code mit dem Schlüsselwort async noch präziser als mit unserer aktuellen Syntax unterschieden wird.

Wir schlagen nicht vor, dass die async with-Anweisung jemals veraltet sein sollte, und befürworten sogar ihre fortgesetzte Verwendung für Einzeilenanweisungen, sodass „async“ das erste Nicht-Leerzeichen-Token jeder Zeile ist, die einen asynchronen Kontextmanager öffnet.

Unser Vorschlag erlaubt dennoch with async some_ctx() und legt Wert auf ein konsistentes Syntaxdesign gegenüber der Erzwingung eines einzelnen Codestils, was wir von Stilrichtlinien, Lintern, Formatierern usw. erwarten. Weitere Diskussionen finden Sie hier.

Begründung

Gemischte synchron/asynchrone Kontextmanager sind in modernen Python-Anwendungen üblich, z. B. bei asynchronen Datenbankverbindungen oder API-Clients und synchronen Dateivorgängen. Die aktuelle Syntax zwingt Entwickler, sich zwischen tief verschachteltem Code oder fehleranfälligen Workarounds wie AsyncExitStack zu entscheiden.

Dieser PEP befasst sich mit dem Problem durch eine minimale Syntaxänderung, die auf bestehenden Mustern aufbaut. Indem einzelne Kontextmanager mit async gekennzeichnet werden können, behalten wir Pythons expliziten Ansatz für asynchronen Code bei und eliminieren gleichzeitig unnötige Verschachtelungen.

Die Implementierung als syntaktischer Zucker sorgt für keinen Laufzeit-Overhead – die neue Syntax wird zu denselben verschachtelten with- und async with-Anweisungen aufgelöst, die Entwickler heute schreiben. Dieser Ansatz erfordert keine neuen Protokolle, keine Änderungen an bestehenden Kontextmanagern und keine neuen Laufzeitverhalten, die verstanden werden müssen.

Spezifikation

Die with (..., async ...):-Syntax wird in eine Sequenz von Kontextmanagern aufgelöst, so wie aktuelle Multi-Kontext-with-Anweisungen, außer dass die mit dem Schlüsselwort async präfigierten das __aenter__ / __aexit__-Protokoll verwenden.

Nur die with-Anweisung wird modifiziert; async with async ctx(): ist ein Syntaxfehler.

Der ast.withitem-Knoten erhält ein neues is_async-Integer-Attribut, analog zum bestehenden is_async-Attribut in ast.comprehension. Für async with-Anweisungselemente ist dieses Attribut immer 1. Für Elemente in einer regulären with-Anweisung ist das Attribut 1, wenn das async-Schlüsselwort vorhanden ist, und andernfalls 0. Dies ermöglicht es der AST, präzise darzustellen, welche Kontextmanager das asynchrone Protokoll verwenden sollten, und gleichzeitig die Abwärtskompatibilität mit vorhandenen AST-Verarbeitungstools zu wahren.

Abwärtskompatibilität

Diese Änderung ist vollständig abwärtskompatibel: Der einzige beobachtbare Unterschied ist, dass bestimmte Syntax, die zuvor einen SyntaxError auslöste, nun erfolgreich ausgeführt wird.

Bibliotheken, die Kontextmanager implementieren (Standardbibliothek und Drittanbieter), funktionieren ohne Änderungen mit der neuen Syntax. Bibliotheken und Tools, die direkt mit Quellcode arbeiten, benötigen kleine Aktualisierungen, wie bei jeder neuen Syntax.

Wie man das lehrt

Wir empfehlen die Einführung von „gemischten Kontextmanagern“ zusammen mit oder unmittelbar nach async with. Ein Tutorial könnte beispielsweise behandeln:

1. Grundlegende Kontextmanager: Beginnen Sie mit einzelnen with-Anweisungen
2. Mehrere Kontextmanager: Zeigen Sie die aktuelle Kommasyntax
3. Asynchrone Kontextmanager: Führen Sie async with ein
4. Gemischte Kontexte: „Markieren Sie jeden asynchronen Kontextmanager mit async“

Abgelehnte Ideen

@contextmanager
async def as_acm(sync_cm):
    with sync_cm as result:
        await sleep(0)
        yield result

async with (
    acquire_lock(),
    as_acm(open('file')) as f,
):
    ...

async with contextlib.AsyncExitStack() as stack:
    await stack.enter_async_context(acquire_lock())
    f = stack.enter_context(open('file', encoding='utf-8'))
    ...

async with multicontext(
    acquire_lock(),
    open('file'),
) as (f, _):
    ...

# Rejected approach
async with (
    acquire_lock(),
    open('config.json') as f,  # actually sync, surprise!
):
    ...

with (
    sync_context() as foo,
    async a_context() as bar,
): ...

with (
    sync_context() as foo,
    async a_context()
): ...

with (
    # sync_context() as foo,
    async a_context()
): ...

with (async a_context()): ...

with async a_context(): ...

Danksagungen

Vielen Dank an Rob Rolls für den Vorschlag with async. Vielen Dank auch an die vielen anderen Personen, mit denen wir dieses Problem und mögliche Lösungen bei den PyCon 2025 Sprints, auf Discourse und bei der Arbeit diskutiert haben.

Urheberrecht

Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.