Dedizierte Template-Literal-Syntax

Dieser PEP schlägt einen neuen String-Präfix vor, der den String als Template-Literal und nicht als gewöhnlichen String deklariert

template = t"Substitute {names:>{field_width}} and {expressions()!r} at runtime"

Dies würde effektiv interpretiert als

template = TemplateLiteral(
    r"Substitute {names:>{field_width}} and {expressions()} at runtime",
    TemplateLiteralText(r"Substitute "),
    TemplateLiteralField("names", names, f">{field_width}", ""),
    TemplateLiteralText(r" and "),
    TemplateLiteralField("expressions()", expressions(), f"", "r"),
)

(Hinweis: Dies ist ein illustratives Beispiel für die Implementierung. Die genaue Syntax der Compile-Zeit-Konstruktion von types.TemplateLiteral gilt als Implementierungsdetail, das nicht vom PEP spezifiziert wird. Insbesondere kann der Compiler die Laufzeitlogik des Standardkonstruktors umgehen, die aufeinanderfolgende Textsegmente erkennt und sie zu einem einzigen Textsegment zusammenfügt, sowie die Laufzeittypen aller bereitgestellten Argumente überprüft).

Die __format__ Methode auf types.TemplateLiteral würde dann die folgenden von str.format() inspirierten Semantiken implementieren

>>> import datetime
>>> name = 'Jane'
>>> age = 50
>>> anniversary = datetime.date(1991, 10, 12)
>>> format(t'My name is {name}, my age next year is {age+1}, my anniversary is {anniversary:%A, %B %d, %Y}.')
'My name is Jane, my age next year is 51, my anniversary is Saturday, October 12, 1991.'
>>> format(t'She said her name is {name!r}.')
"She said her name is 'Jane'."

Die Syntax von Template-Literalen würde auf PEP 701 basieren und weitgehend die gleiche Syntax für den String-Teil des Templates verwenden. Abgesehen von der Verwendung eines anderen Präfixes ist die einzige syntaktische Änderung die Definition und Handhabung von Konvertierungsspezifizierern, sowohl um !() als Standard-Konvertierungsspezifizierer zu erlauben, um die Auswertung eines Feldes zur Rendering-Zeit anzufordern, als auch um benutzerdefinierten Renderern zu erlauben, benutzerdefinierte Konvertierungsspezifizierer zu definieren.

Dieser PEP schlägt keine Entfernung oder Deprezierung bestehender String-Formatierungsmechanismen vor, da diese weiterhin wertvoll bleiben, wenn nicht direkt im Quellcode der Anwendung vorhandene Strings formatiert werden.

Lazy-Feld-Evaluierungs-Konvertierungsspezifizierer

Zusätzlich zur bestehenden Unterstützung für die Konvertierungsspezifizierer a, r und s werden str.format(), str.format_map() und string.Formatter aktualisiert, um () als Konvertierungsspezifizierer zu akzeptieren, der „rufe den interpolierten Wert auf“ bedeutet.

Um die Anwendung der Standard-Konvertierungsspezifizierer in benutzerdefinierten Template-Rendering-Funktionen zu unterstützen, wird eine neue Funktion operator.convert_field() hinzugefügt.

Die Signatur und das Verhalten des Built-in format() werden ebenfalls aktualisiert, um einen Konvertierungsspezifizierer als drittes optionales Argument zu akzeptieren. Wenn ein nicht-leerer Konvertierungsspezifizierer angegeben wird, wird der Wert mit operator.convert_field() konvertiert, bevor die __format__ Methode aufgerufen wird.

Benutzerdefinierte Konvertierungsspezifizierer

Um zusätzliche feldspezifische Direktiven an benutzerdefinierte Rendering-Funktionen übergeben zu können, auf eine Weise, die immer noch die Formatierung des Templates mit dem Standard-Renderer ermöglicht, darf das Feld für den Konvertierungsspezifizierer ein zweites ! Zeichen enthalten.

operator.convert_field() und format() (und damit die Standard-Rendering-Methode TemplateLiteral.render) ignorieren dieses Zeichen und jeden nachfolgenden Text im Feld des Konvertierungsspezifizierers.

str.format(), str.format_map() und string.Formatter werden ebenfalls aktualisiert, um benutzerdefinierte Konvertierungsspezifizierer zu akzeptieren (und zu ignorieren).

Template-Renderer für POSIX-Shell-Befehle

Sowohl als praktische Demonstration der Vorteile der Unterstützung für verzögertes Rendering als auch als eigenständiges wertvolles Feature wird dem Modul shlex ein neuer sh Template-Renderer hinzugefügt. Dieser Renderer erzeugt Strings, bei denen alle interpolierten Felder mit shlex.quote() escaped werden.

Die subprocess.Popen API (und darauf aufbauende höherstufige APIs wie subprocess.run()) werden aktualisiert, um Interpolationstemplates zu akzeptieren und sie gemäß dem neuen shlex.sh Renderer zu behandeln.

Zusammenfassung der Unterschiede zu f-Strings

Die Hauptunterschiede zwischen f-Strings und t-Strings sind:

• der Präfix t (Template-Literal) bedeutet verzögerte Renderung, verwendet aber ansonsten weitgehend die gleiche Syntax und Semantik wie formatierte Strings
• Template-Literale sind zur Laufzeit als neue Art von Objekten (types.TemplateLiteral) verfügbar
• die Standard-Renderung, die von formatierten Strings verwendet wird, wird auf einem Template-Literal-Objekt durch Aufruf von format(template) aufgerufen, anstatt implizit im kompilierten Code zu erfolgen
• im Gegensatz zu f-Strings (bei denen Konvertierungsspezifizierer direkt im Compiler behandelt werden) werden t-String-Konvertierungsspezifizierer zur Render-Zeit von der Rendering-Funktion behandelt
• der neue Konvertierungsspezifizierer !() zeigt an, dass der Feld-Ausdruck ein aufrufbares Objekt ist, das beim Verwenden der Standard-Rendering-Funktion format() aufgerufen werden soll. Dieser Spezifizierer wird ausdrücklich *nicht* zu f-Strings hinzugefügt (da er dort sinnlos ist).
• ein zweites ! ist in t-String-Konvertierungsspezifizierern erlaubt (wobei nachfolgender Text ignoriert wird), um benutzerdefinierten Template-Rendering-Funktionen zu erlauben, benutzerdefinierte Konvertierungsspezifizierer zu akzeptieren, ohne die Standard-Rendering-Methode TemplateLiteral.render() zu beeinträchtigen. Dieses Feature wird ausdrücklich *nicht* zu f-Strings hinzugefügt (da es dort sinnlos ist).
• während f"Message {here}" von f-Strings *semantisch* äquivalent zu format(t"Message {here}") wäre, werden f-Strings weiterhin direkt im Compiler unterstützt und vermeiden daher den Laufzeit-Overhead der tatsächlichen Nutzung der verzögerten Rendering-Maschinerie, die für t-Strings erforderlich ist

Zusammenfassung der Unterschiede zu getaggten Strings

Als getaggte Strings erstmals vorgeschlagen wurden, gab es mehrere bemerkenswerte Unterschiede zum Vorschlag in PEP 501, abgesehen vom Oberflächen-Syntaxunterschied, ob Renderfunktionsaufrufe als render(t"template literal") oder als render"template literal" geschrieben werden.

Im Laufe der ursprünglichen Diskussion zu PEP 750 wurden viele dieser Unterschiede eliminiert, entweder indem PEP 501 diesen Aspekt des Vorschlags von PEP 750 übernahm (wie das verzögerte Anwenden von Konvertierungsspezifizierern) oder indem PEP 750 geändert wurde, um einen Aspekt des Vorschlags von PEP 501 beizubehalten (wie die Definition eines dedizierten Typs zur Aufnahme von Template-Segmenten anstatt deren Darstellung als einfache Sequenzen).

Der Hauptunterschied, der verbleibt, ist, dass dieser PEP argumentiert, dass die Hinzufügung *nur* des t-String-Präfixes eine ausreichende Verbesserung darstellt, um alle in PEP 750 beschriebenen gewünschten Vorteile zu erzielen. Die Erweiterung zu einer generalisierten „getaggten String“-Syntax ist nicht notwendig und verursacht zusätzliche Probleme, die vermieden werden können.

Die beiden PEPs unterscheiden sich auch in ihren vorgeschlagenen Ansätzen zur Handhabung der verzögerten Auswertung von Template-Feldern.

Obwohl es *andere* Unterschiede zwischen den beiden Vorschlägen gibt, sind diese Unterschiede eher kosmetischer als substanzieller Natur. Insbesondere:

• Dieser PEP schlägt unterschiedliche Namen für die Protokolle des strukturellen Tippens vor
• Dieser PEP schlägt spezifische Namen für die konkreten Implementierungstypen vor
• Dieser PEP schlägt genaue Details für die vorgeschlagenen APIs der konkreten Implementierungstypen vor (einschließlich Unterstützung für Verkettung und Wiederholung, die nicht Teil der Protokolle des strukturellen Tippens sind)
• Dieser PEP schlägt Änderungen am bestehenden Built-in format() vor, um es direkt als Template-Feld-Renderer nutzbar zu machen

Die beiden PEPs unterscheiden sich auch darin, *wie* sie ihre Argumente für die Unterstützung verzögerter Renderung darlegen. Dieser PEP konzentriert sich stärker auf das konkrete Implementierungskonzept der Verwendung von Template-Literalen, um die Schritte „Interpolation“ und „Rendering“ bei der f-String-Verarbeitung zeitlich zu trennen und dies dann zu nutzen, um die potenziellen Code-Injection-Risiken zu reduzieren, die mit dem Missbrauch von f-Strings verbunden sind. PEP 750 konzentriert sich stärker darauf, wie native Templating-Unterstützung Verhaltensweisen ermöglicht, die über vorhandene stringbasierte Templating-Methoden schwer oder unmöglich zu erreichen sind. Wie bei den oben genannten kosmetischen Unterschieden handelt es sich hierbei eher um einen Stilunterschied als um einen Substanzunterschied.

Rendering von Templates

Die Implementierung von TemplateLiteral.render definiert den Rendering-Prozess in Form der folgenden Renderer:

• eine übergeordnete render_template Operation, die definiert, wie die Sequenz aus gerenderten Text- und Feldsegmenten zu einem vollständig gerenderten Ergebnis zusammengesetzt wird. Der Standard-Template-Renderer ist die String-Verkettung mittels ''.join.
• eine pro Textsegment render_text Operation, die die einzelnen Literal-Textsegmente innerhalb des Templates empfängt. Der Standard-Textrenderer ist der eingebaute str Konstruktor.
• eine pro Feldsegment render_field Operation, die den Feldwert, den Format-Spezifizierer und den Konvertierungs-Spezifizierer für Substitutionsfelder innerhalb des Templates empfängt. Der Standard-Feldrenderer ist der eingebaute format().

Gegeben die obige geparste Template-Darstellung, wären die Semantiken des Template-Renderings äquivalent zu folgendem:

def render(self, *, render_template=''.join, render_text=str, render_field=format):
    rendered_segments = []
    for segment in self._segments:
        match segment:
            case TemplateLiteralText() as text_segment:
                rendered_segments.append(render_text(text_segment))
            case TemplateLiteralField() as field_segment:
                rendered_segments.append(render_field(*field_segment[1:]))
    return render_template(rendered_segments)

Format-Spezifizierer

Die Syntax und Verarbeitung von Feld-Spezifizierern in t-Strings ist so definiert, dass sie der von f-Strings entspricht.

Dies schließt ein, dass Feld-Spezifizierer selbst f-String-Substitutionsfelder enthalten können. Der rohe Text der Feld-Spezifizierer (ohne Verarbeitung von Substitutionsfeldern) bleibt als Teil des vollständigen rohen Template-Strings erhalten.

Die geparisierten Feld-Spezifizierer empfangen den Feld-Spezifizierer-String mit bereits aufgelösten Substitutionen. Das Präfix : wird ebenfalls weggelassen.

Abgesehen davon, dass sie während des Parsens vom Substitutionsausdruck getrennt werden, werden Format-Spezifizierer vom Interpolationstemplatparser ansonsten als undurchsichtige Strings behandelt – die Zuweisung von Semantik zu diesen (oder alternativ deren Verbot) wird zur Rendering-Zeit vom Feld-Renderer gehandhabt.

Konvertierungsspezifizierer

Zusätzlich zur bestehenden Unterstützung für die Konvertierungsspezifizierer a, r und s werden str.format() und str.format_map() aktualisiert, um () als Konvertierungsspezifizierer zu akzeptieren, der „rufe den interpolierten Wert auf“ bedeutet.

Wo PEP 701 Konvertierungsspezifizierer auf NAME-Token beschränkt, wird dieser PEP stattdessen FSTRING_MIDDLE-Tokens erlauben (so dass nur {, } und : disallowed sind). Diese Änderung wird hauptsächlich vorgenommen, um die verzögerte Feld-Renderung mit dem Konvertierungsspezifizierer !() zu unterstützen, erlaubt aber auch benutzerdefinierten Rendering-Funktionen mehr Flexibilität bei der Definition eigener Konvertierungsspezifizierer im Vergleich zu denen, die für den Standard-Feld-Renderer von format() definiert sind.

Konvertierungsspezifizierer werden immer noch als einfache Strings behandelt und unterstützen KEINE Substitution von Feldern.

Die geparisierten Konvertierungsspezifizierer empfangen den Konvertierungsspezifizierer-String mit weggelassenem ! Präfix.

Um benutzerdefinierten Vorlagenrenderern zu ermöglichen, ihre eigenen benutzerdefinierten Konvertierungsspezifizierer zu definieren, ohne dass der Standard-Renderer fehlschlägt, werden Konvertierungsspezifizierer nun eine benutzerdefinierte Suffixkomponente enthalten, der ein zweites !-Zeichen vorangestellt ist. Das bedeutet, dass !!<custom>, !a!<custom>, !r!<custom>, !s!<custom> und !()!<custom> alle gültige Konvertierungsspezifizierer in einem Vorlagenliteral wären.

Wie oben beschrieben, unterstützt das Standard-Rendering die ursprünglichen !a, !r und !s Konvertierungsspezifizierer, die in PEP 3101 definiert sind, zusammen mit dem neuen !() Lazy-Feld-Evaluierungs-Konvertierungsspezifizierer, der in dieser PEP definiert ist. Das Standard-Rendering ignoriert benutzerdefinierte Konvertierungsspezifizierer-Suffixe.

Die vollständige Zuordnung zwischen den Standard-Konvertierungsspezifizierern und den Spezialmethoden, die auf dem interpolierten Wert aufgerufen werden, wenn das Feld gerendert wird

• Keine Konvertierung (leerer String): __format__ (mit Format-Spezifizierer als Parameter)
• a: __repr__ (gemäß der eingebauten Funktion ascii())
• r: __repr__ (gemäß der eingebauten Funktion repr())
• s: __str__ (gemäß der eingebauten Funktion str)
• (): __call__ (ohne Parameter)

Wenn eine Konvertierung stattfindet, wird __format__ (mit dem Format-Spezifizierer) auf dem Ergebnis der Konvertierung aufgerufen, anstatt auf dem ursprünglichen Objekt.

Die Änderungen an format() und die Ergänzung von operator.convert_field() erleichtern es benutzerdefinierten Renderern, auch die Standard-Konvertierungsspezifizierer zu unterstützen.

f-Strings selbst werden den neuen !()-Konvertierungsspezifizierer NICHT unterstützen (da er redundant ist, wenn Wertinterpolation und Wert-Rendering gleichzeitig stattfinden). Sie werden auch NICHT die Verwendung benutzerdefinierter Konvertierungsspezifizierer unterstützen (da die Rendering-Funktion zur Kompilierzeit bekannt ist und die benutzerdefinierten Spezifizierer nicht verwendet werden).

Neue Feldkonvertierungs-API im operator-Modul

Um die Anwendung der Standard-Konvertierungsspezifizierer in benutzerdefinierten Vorlagen-Rendering-Funktionen zu unterstützen, wird eine neue Funktion operator.convert_field() hinzugefügt

def convert_field(value, conversion_spec=''):
    """Apply the given string formatting conversion specifier to the given value"""
    std_spec, sep, custom_spec = conversion_spec.partition("!")
    match std_spec:
        case '':
            return value
        case 'a':
            return ascii(value)
        case 'r':
            return repr(value)
        case 's':
            return str(value)
        case '()':
            return value()
    if not sep:
        err = f"Invalid conversion specifier {std_spec!r}"
    else:
        err = f"Invalid conversion specifier {std_spec!r} in {conversion_spec!r}"
    raise ValueError(f"{err}: expected '', 'a', 'r', 's' or '()')

Konvertierungsspezifizierer-Parameter zu format() hinzugefügt

Die Signatur und das Verhalten der eingebauten Funktion format() werden aktualisiert

def format(value, format_spec='', conversion_spec=''):
    if conversion_spec:
        value_to_format = operator.convert_field(value)
    else:
        value_to_format = value
    return type(value_to_format).__format__(value, format_spec)

Wenn ein nicht-leerer Konvertierungsspezifizierer angegeben wird, wird der Wert mit operator.convert_field() konvertiert, bevor die Methode __format__ aufgerufen wird.

Die Signatur der Spezialmethode __format__ ändert sich NICHT (nur Format-Spezifizierer werden vom zu formatierenden Objekt behandelt).

Strukturelles Tippen und Duck-Typing

Um benutzerdefinierten Renderern die Akzeptanz alternativer Vorlagenimplementierungen zu ermöglichen (anstatt eng an die nativen Vorlagenliteral-Typen gebunden zu sein), werden die folgenden strukturellen Protokolle dem Modul typing hinzugefügt

@runtime_checkable
class TemplateText(Protocol):
    # Renamed version of PEP 750's Decoded protocol
    def __str__(self) -> str:
        ...

    raw: str

@runtime_checkable
class TemplateField(Protocol):
    # Renamed and modified version of PEP 750's Interpolation protocol
    def __len__(self):
        ...

    def __getitem__(self, index: int):
        ...

    def __str__(self) -> str:
        ...

    expr: str
    value: Any
    format_spec: str | None = None
    conversion_spec: str | None = None

@runtime_checkable
class InterpolationTemplate(Protocol):
    # Corresponds to PEP 750's Template protocol
    def __iter__(self) -> Iterable[TemplateText|TemplateField]:
        ...

    raw_template: str

Beachten Sie, dass die strukturellen Protokoll-APIs erheblich schmaler sind als die vollständigen Implementierungs-APIs für TemplateLiteralText, TemplateLiteralField und TemplateLiteral.

Code, der Interpolationsvorlagen akzeptieren und spezifische Handhabung dafür definieren möchte, ohne eine Abhängigkeit vom Modul typing einzuführen oder den Code auf die Handhabung konkreter Vorlagenliteral-Typen zu beschränken, sollte stattdessen eine Prüfung auf Attributexistenz auf raw_template durchführen.

Schreiben benutzerdefinierter Renderer

Das Schreiben eines benutzerdefinierten Renderers erfordert keine spezielle Syntax. Stattdessen sind benutzerdefinierte Renderer gewöhnliche aufrufbare Objekte, die eine Interpolationsvorlage direkt verarbeiten, entweder durch Aufrufen der Methode render() mit alternativen Implementierungen für render_template, render_text und/oder render_field oder durch direkten Zugriff auf die Datenattribute der Vorlage.

Zum Beispiel würde die folgende Funktion eine Vorlage rendern, indem sie die repr-Implementierungen von Objekten anstelle ihrer nativen Formatierungsunterstützung verwendet

def repr_format(template):
    def render_field(value, format_spec, conversion_spec):
        converted_value = operator.convert_field(value, conversion_spec)
        return format(repr(converted_value), format_spec)
    return template.render(render_field=render_field)

Der dargestellte benutzerdefinierte Renderer berücksichtigt die Konvertierungsspezifizierer in der ursprünglichen Vorlage, aber es ist auch möglich, sie zu ignorieren und die interpolierten Werte direkt zu rendern

def input_repr_format(template):
    def render_field(value, format_spec, __):
        return format(repr(value), format_spec)
    return template.render(render_field=render_field)

Beim Schreiben benutzerdefinierter Renderer ist zu beachten, dass der Rückgabetyp des gesamten Rendering-Vorgangs durch den Rückgabetyp des übergebenen render_template-Aufrufs bestimmt wird. Während dies für Formatierungszwecke immer noch ein String sein wird, ist die Erzeugung von Nicht-String-Objekten *erlaubt*. Zum Beispiel könnte ein benutzerdefinierter SQL-Vorlagen-Renderer einen Aufruf von sqlalchemy.sql.text beinhalten, der ein SQL Alchemy Query-Objekt erzeugt. Ein Vorlagen-Renderer, der mit Subprozessaufrufen zu tun hat, könnte eine Zeichenkettenfolge erzeugen, die für die Übergabe an subprocess.run geeignet ist, oder er könnte sogar subprocess.run direkt aufrufen und das Ergebnis zurückgeben.

Auch Nicht-Strings können von render_text und render_field zurückgegeben werden, solange sie mit einer render_template-Implementierung gepaart sind, die dieses Verhalten erwartet.

Benutzerdefinierte Renderer, die den in PEP 750 beschriebenen Mustervergleichsstil verwenden, werden ebenfalls unterstützt

# Use the structural typing protocols rather than the concrete implementation types
from typing import InterpolationTemplate, TemplateText, TemplateField

def greet(template: InterpolationTemplate) -> str:
    """Render an interpolation template using structural pattern matching."""
    result = []
    for segment in template:
        match segment:
            match segment:
                case TemplateText() as text_segment:
                    result.append(text_segment)
                case TemplateField() as field_segment:
                    result.append(str(field_segment).upper())
    return f"{''.join(result)}!"

Auswertung von Ausdrücken

Wie bei f-Strings werden die Unterausdrücke, die aus der Interpolationsvorlage extrahiert werden, im Kontext ausgewertet, in dem das Vorlagenliteral erscheint. Das bedeutet, dass der Ausdruck vollständigen Zugriff auf lokale, nicht-lokale und globale Variablen hat. Jede gültige Python-Ausdruck kann innerhalb von {} verwendet werden, einschließlich Funktions- und Methodenaufrufen.

Da die Substitutionsausdrücke dort ausgewertet werden, wo der String im Quellcode erscheint, gibt es keine zusätzlichen Sicherheitsbedenken hinsichtlich des Inhalts des Ausdrucks selbst, da man auch einfach denselben Ausdruck geschrieben und die Laufzeitfeldanalyse verwendet hätte.

>>> bar=10
>>> def foo(data):
...   return data + 20
...
>>> str(t'input={bar}, output={foo(bar)}')
'input=10, output=30'

Ist im Wesentlichen gleichwertig mit

>>> 'input={}, output={}'.format(bar, foo(bar))
'input=10, output=30'

Umgang mit Code-Injection-Angriffen

Die PEP 498 formatierten String-Syntax macht es attraktiv, Code wie den folgenden zu schreiben

runquery(f"SELECT {column} FROM {table};")
runcommand(f"cat {filename}")
return_response(f"<html><body>{response.body}</body></html>")

Dies sind alles potenzielle Vektoren für Code-Injektionsangriffe, wenn eine der interpolierten Variablen aus einer nicht vertrauenswürdigen Quelle stammt. Der spezifische Vorschlag in dieser PEP soll es einfach machen, anwendungsfallspezifische Renderer zu schreiben, die interpolierte Werte für den relevanten Sicherheitskontext entsprechend quotieren.

runquery(sql(t"SELECT {column} FROM {table} WHERE column={value};"))
runcommand(sh(t"cat {filename}"))
return_response(html(t"<html><body>{response.body}</body></html>"))

Diese PEP deckt nicht die sofortige Aufnahme aller solchen Renderer in die Standardbibliothek ab (obwohl einer für Shell-Escaping vorgeschlagen wird), sondern schlägt vor, sicherzustellen, dass sie leicht von Drittanbieterbibliotheken bereitgestellt werden können und möglicherweise zu einem späteren Zeitpunkt in die Standardbibliothek aufgenommen werden können.

Im Laufe der Zeit wird erwartet, dass APIs, die potenziell gefährliche String-Eingaben verarbeiten, aktualisiert werden, um Interpolationsvorlagen nativ zu akzeptieren, was es ermöglicht, problematische Codebeispiele einfach durch Ersetzen des f-String-Präfixes durch ein t zu beheben.

runquery(t"SELECT {column} FROM {table};")
runcommand(t"cat {filename}")
return_response(t"<html><body>{response.body}</body></html>")

Es wird vorgeschlagen, einen Renderer im Modul shlex aufzunehmen, der ein POSIX-Shell-ähnlicheres Erlebnis für den Zugriff auf externe Programme bietet, ohne die erheblichen Risiken, die mit der Ausführung von os.system oder der Aktivierung der System-Shell bei Verwendung der subprocess-Modul-APIs verbunden sind. Dieser Renderer bietet eine Schnittstelle zum Ausführen externer Programme, die von der des Julia-Programmiersprache inspiriert ist, nur mit der Backtick-basierten \`cat $filename\`-Syntax, die durch t"cat {filename}"-artige Vorlagenliterale ersetzt wird. Siehe mehr im Abschnitt Renderer für Shell-Escaping zu shlex hinzugefügt.