CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="color-scheme" content="light dark"> <title>PEP 750 – Template Strings | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0750/"> <link rel="stylesheet" href="../_static/style.css" type="text/css"> <link rel="stylesheet" href="../_static/mq.css" type="text/css"> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light"> <link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark"> <link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss"> <meta property="og:title" content='PEP 750 – Template Strings | peps.python.org'> <meta property="og:description" content="This PEP introduces template strings for custom string processing."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0750/"> <meta property="og:site_name" content="Python Enhancement Proposals (PEPs)"> <meta property="og:image" content="https://peps.python.org/_static/og-image.png"> <meta property="og:image:alt" content="Python PEPs"> <meta property="og:image:width" content="200"> <meta property="og:image:height" content="200"> <meta name="description" content="This PEP introduces template strings for custom string processing."> <meta name="theme-color" content="#3776ab"> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all"> <title>Following system colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="9"></circle> <path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path> </svg> </symbol> <symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all"> <title>Selected dark colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path stroke="none" d="M0 0h24v24H0z" fill="none"></path> <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path> </svg> </symbol> <symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all"> <title>Selected light colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="5"></circle> <line x1="12" y1="1" x2="12" y2="3"></line> <line x1="12" y1="21" x2="12" y2="23"></line> <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> <line x1="1" y1="12" x2="3" y2="12"></line> <line x1="21" y1="12" x2="23" y2="12"></line> <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> </svg> </symbol> </svg> <script> document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto" </script> <section id="pep-page-section"> <header> <h1>Python Enhancement Proposals</h1> <ul class="breadcrumbs"> <li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li> <li><a href="../pep-0000/">PEP Index</a> » </li> <li>PEP 750</li> </ul> <button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())"> <svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg> Toggle light / dark / auto colour theme </button> </header> <article> <section id="pep-content"> <h1 class="page-title">PEP 750 – Template Strings</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Jim Baker <jim.baker at python.org>, Guido van Rossum <guido at python.org>, Paul Everitt <pauleveritt at me.com>, Koudai Aono <koxudaxi at gmail.com>, Lysandros Nikolaou <lisandrosnik at gmail.com>, Dave Peck <davepeck at davepeck.org></dd> <dt class="field-even">Discussions-To:</dt> <dd class="field-even"><a class="reference external" href="https://discuss.python.org/t/71594">Discourse thread</a></dd> <dt class="field-odd">Status:</dt> <dd class="field-odd"><abbr title="Proposal under active discussion and revision">Draft</abbr></dd> <dt class="field-even">Type:</dt> <dd class="field-even"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd> <dt class="field-odd">Created:</dt> <dd class="field-odd">08-Jul-2024</dd> <dt class="field-even">Python-Version:</dt> <dd class="field-even">3.14</dd> <dt class="field-odd">Post-History:</dt> <dd class="field-odd"><a class="reference external" href="https://discuss.python.org/t/60408" title="Discourse thread">09-Aug-2024</a>, <a class="reference external" href="https://discuss.python.org/t/60408/201" title="Discourse message">17-Oct-2024</a>, <a class="reference external" href="https://discuss.python.org/t/60408/226" title="Discourse message">21-Oct-2024</a>, <a class="reference external" href="https://discuss.python.org/t/71594" title="Discourse thread">18-Nov-2024</a></dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#relationship-with-other-peps">Relationship With Other PEPs</a></li> <li><a class="reference internal" href="#motivation">Motivation</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#template-string-literals">Template String Literals</a></li> <li><a class="reference internal" href="#the-template-type">The <code class="docutils literal notranslate">Template</code> Type</a></li> <li><a class="reference internal" href="#the-interpolation-type">The <code class="docutils literal notranslate">Interpolation</code> Type</a></li> <li><a class="reference internal" href="#convenience-accessors-in-template">Convenience Accessors in <code class="docutils literal notranslate">Template</code></a></li> <li><a class="reference internal" href="#processing-template-strings">Processing Template Strings</a></li> <li><a class="reference internal" href="#template-string-concatenation">Template String Concatenation</a></li> <li><a class="reference internal" href="#template-and-interpolation-equality">Template and Interpolation Equality</a></li> <li><a class="reference internal" href="#no-support-for-ordering">No Support for Ordering</a></li> <li><a class="reference internal" href="#support-for-the-debug-specifier">Support for the debug specifier (<code class="docutils literal notranslate">=</code>)</a></li> <li><a class="reference internal" href="#raw-template-strings">Raw Template Strings</a></li> <li><a class="reference internal" href="#interpolation-expression-evaluation">Interpolation Expression Evaluation</a></li> <li><a class="reference internal" href="#exceptions">Exceptions</a></li> <li><a class="reference internal" href="#no-template-str-implementation">No <code class="docutils literal notranslate">Template.__str__()</code> Implementation</a></li> </ul> </li> <li><a class="reference internal" href="#examples">Examples</a><ul> <li><a class="reference internal" href="#example-implementing-f-strings-with-t-strings">Example: Implementing f-strings with t-strings</a></li> <li><a class="reference internal" href="#example-structured-logging">Example: Structured Logging</a><ul> <li><a class="reference internal" href="#approach-1-custom-log-messages">Approach 1: Custom Log Messages</a></li> <li><a class="reference internal" href="#approach-2-custom-formatters">Approach 2: Custom Formatters</a></li> </ul> </li> <li><a class="reference internal" href="#example-html-templating">Example: HTML Templating</a></li> </ul> </li> <li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a></li> <li><a class="reference internal" href="#security-implications">Security Implications</a></li> <li><a class="reference internal" href="#how-to-teach-this">How To Teach This</a></li> <li><a class="reference internal" href="#why-another-templating-approach">Why another templating approach?</a></li> <li><a class="reference internal" href="#common-patterns-seen-in-processing-templates">Common Patterns Seen in Processing Templates</a><ul> <li><a class="reference internal" href="#structural-pattern-matching">Structural Pattern Matching</a></li> <li><a class="reference internal" href="#memoizing">Memoizing</a></li> <li><a class="reference internal" href="#parsing-to-intermediate-representations">Parsing to Intermediate Representations</a></li> <li><a class="reference internal" href="#context-sensitive-processing-of-interpolations">Context-sensitive Processing of Interpolations</a></li> <li><a class="reference internal" href="#nested-template-strings">Nested Template Strings</a></li> <li><a class="reference internal" href="#approaches-to-lazy-evaluation">Approaches to Lazy Evaluation</a></li> <li><a class="reference internal" href="#approaches-to-asynchronous-evaluation">Approaches to Asynchronous Evaluation</a></li> <li><a class="reference internal" href="#approaches-to-template-reuse">Approaches to Template Reuse</a></li> <li><a class="reference internal" href="#relation-to-format-strings">Relation to Format Strings</a></li> </ul> </li> <li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#arbitrary-string-literal-prefixes">Arbitrary String Literal Prefixes</a></li> <li><a class="reference internal" href="#delayed-evaluation-of-interpolations">Delayed Evaluation of Interpolations</a></li> <li><a class="reference internal" href="#making-template-and-interpolation-into-protocols">Making <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> Into Protocols</a></li> <li><a class="reference internal" href="#overridden-eq-and-hash-for-template-and-interpolation">Overridden <code class="docutils literal notranslate">__eq__</code> and <code class="docutils literal notranslate">__hash__</code> for <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code></a></li> <li><a class="reference internal" href="#an-additional-decoded-type">An Additional <code class="docutils literal notranslate">Decoded</code> Type</a></li> <li><a class="reference internal" href="#the-final-home-for-template-and-interpolation">The Final Home for <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code></a></li> <li><a class="reference internal" href="#enable-full-reconstruction-of-original-template-literal">Enable Full Reconstruction of Original Template Literal</a></li> <li><a class="reference internal" href="#disallowing-string-concatenation">Disallowing String Concatenation</a></li> <li><a class="reference internal" href="#arbitrary-conversion-values">Arbitrary Conversion Values</a></li> <li><a class="reference internal" href="#removing-conv-from-interpolation">Removing <code class="docutils literal notranslate">conv</code> From <code class="docutils literal notranslate">Interpolation</code></a></li> <li><a class="reference internal" href="#alternate-interpolation-symbols">Alternate Interpolation Symbols</a></li> <li><a class="reference internal" href="#alternate-layouts-for-template">Alternate Layouts for <code class="docutils literal notranslate">Template</code></a></li> <li><a class="reference internal" href="#mechanism-to-describe-the-kind-of-template">Mechanism to Describe the “Kind” of Template</a></li> <li><a class="reference internal" href="#binary-template-strings">Binary Template Strings</a></li> </ul> </li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> This PEP introduces template strings for custom string processing. Template strings are a generalization of f-strings, using a <code class="docutils literal notranslate">t</code> in place of the <code class="docutils literal notranslate">f</code> prefix. Instead of evaluating to <code class="docutils literal notranslate">str</code>, t-strings evaluate to a new type, <code class="docutils literal notranslate">Template</code>: <div class="highlight-python notranslate"><div class="highlight"><pre>template: Template = t"Hello {name}" </pre></div> </div> Templates provide developers with access to the string and its interpolated values before they are combined. This brings native flexible string processing to the Python language and enables safety checks, web templating, domain-specific languages, and more. </section> <section id="relationship-with-other-peps"> <h2><a class="toc-backref" href="#relationship-with-other-peps" role="doc-backlink">Relationship With Other PEPs</a></h2> Python introduced f-strings in Python 3.6 with <a class="pep reference internal" href="../pep-0498/" title="PEP 498 – Literal String Interpolation">PEP 498</a>. The grammar was then formalized in <a class="pep reference internal" href="../pep-0701/" title="PEP 701 – Syntactic formalization of f-strings">PEP 701</a> which also lifted some restrictions. This PEP is based on PEP 701. At nearly the same time PEP 498 arrived, <a class="pep reference internal" href="../pep-0501/" title="PEP 501 – General purpose template literal strings">PEP 501</a> was written to provide “i-strings” – that is, “interpolation template strings”. The PEP was deferred pending further experience with f-strings. Work on this PEP was resumed by a different author in March 2023, introducing “t-strings” as template literal strings, and built atop PEP 701. The authors of this PEP consider it to be a generalization and simplification of the updated work in PEP 501. (That PEP has also recently been updated to reflect the new ideas in this PEP.) </section> <section id="motivation"> <h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2> Python f-strings are easy to use and very popular. Over time, however, developers have encountered limitations that make them <a class="reference external" href="https://docs.djangoproject.com/en/5.1/ref/utils/#django.utils.html.format_html">unsuitable for certain use cases</a>. In particular, f-strings provide no way to intercept and transform interpolated values before they are combined into a final string. As a result, incautious use of f-strings can lead to security vulnerabilities. For example, a user executing a SQL query with <a class="reference external" href="https://docs.python.org/3/library/sqlite3.html#module-sqlite3" title="(in Python v3.13)"><code class="docutils literal notranslate">sqlite3</code></a> may be tempted to use an f-string to embed values into their SQL expression, which could lead to a <a class="reference external" href="https://en.wikipedia.org/wiki/SQL_injection">SQL injection attack</a>. Or, a developer building HTML may include unescaped user input in the string, leading to a <a class="reference external" href="https://en.wikipedia.org/wiki/Cross-site_scripting">cross-site scripting (XSS)</a> vulnerability. More broadly, the inability to transform interpolated values before they are combined into a final string limits the utility of f-strings in more complex string processing tasks. Template strings address these problems by providing developers with access to the string and its interpolated values. For example, imagine we want to generate some HTML. Using template strings, we can define an <code class="docutils literal notranslate">html()</code> function that allows us to automatically sanitize content: <div class="highlight-python notranslate"><div class="highlight"><pre>evil = "<script>alert('evil')</script>" template = t"{evil}" assert html(template) == "&lt;script&gt;alert('evil')&lt;/script&gt;" </pre></div> </div> Likewise, our hypothetical <code class="docutils literal notranslate">html()</code> function can make it easy for developers to add attributes to HTML elements using a dictionary: <div class="highlight-python notranslate"><div class="highlight"><pre>attributes = {"src": "shrubbery.jpg", "alt": "looks nice"} template = t"<img {attributes} />" assert html(template) == '<img src="shrubbery.jpg" alt="looks nice" />' </pre></div> </div> Neither of these examples is possible with f-strings. By providing a mechanism to intercept and transform interpolated values, template strings enable a wide range of string processing use cases. </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> <section id="template-string-literals"> <h3><a class="toc-backref" href="#template-string-literals" role="doc-backlink">Template String Literals</a></h3> This PEP introduces a new string prefix, <code class="docutils literal notranslate">t</code>, to define template string literals. These literals resolve to a new type, <code class="docutils literal notranslate">Template</code>, found in the standard library module <code class="docutils literal notranslate"><<TBD>></code>. The following code creates a <code class="docutils literal notranslate">Template</code> instance: <div class="highlight-python notranslate"><div class="highlight"><pre>from TBD import Template template = t"This is a template string." assert isinstance(template, Template) </pre></div> </div> Template string literals support the full syntax of <a class="pep reference internal" href="../pep-0701/" title="PEP 701 – Syntactic formalization of f-strings">PEP 701</a>. This includes the ability to nest template strings within interpolations, as well as the ability to use all valid quote marks (<code class="docutils literal notranslate">'</code>, <code class="docutils literal notranslate">"</code>, <code class="docutils literal notranslate">'''</code>, and <code class="docutils literal notranslate">"""</code>). Like other string prefixes, the <code class="docutils literal notranslate">t</code> prefix must immediately precede the quote. Like f-strings, both lowercase <code class="docutils literal notranslate">t</code> and uppercase <code class="docutils literal notranslate">T</code> prefixes are supported. Like f-strings, t-strings may not be combined with <code class="docutils literal notranslate">u</code> or the <code class="docutils literal notranslate">b</code> prefix. Additionally, f-strings and t-strings cannot be combined, so the <code class="docutils literal notranslate">ft</code> prefix is invalid. t-strings may be combined with the <code class="docutils literal notranslate">r</code> prefix; see the <a class="reference internal" href="#raw-template-strings">Raw Template Strings</a> section below for more information. </section> <section id="the-template-type"> <h3><a class="toc-backref" href="#the-template-type" role="doc-backlink">The <code class="docutils literal notranslate">Template</code> Type</a></h3> Template strings evaluate to an instance of a new immutable type, <code class="docutils literal notranslate"><<TBD>>.Template</code>: <div class="highlight-python notranslate"><div class="highlight"><pre>class Template: strings: tuple[str, ...] """ A non-empty tuple of the string parts of the template, with N+1 items, where N is the number of interpolations in the template. """ interpolations: tuple[Interpolation, ...] """ A tuple of the interpolation parts of the template. This will be an empty tuple if there are no interpolations. """ def __new__(cls, *args: str | Interpolation): """ Create a new Template instance. Arguments can be provided in any order. """ ... @property def values(self) -> tuple[object, ...]: """ Return a tuple of the `value` attributes of each Interpolation in the template. This will be an empty tuple if there are no interpolations. """ ... def __iter__(self) -> Iterator[str | Interpolation]: """ Iterate over the string parts and interpolations in the template. These may appear in any order. Empty strings will not be included. """ ... </pre></div> </div> The <code class="docutils literal notranslate">strings</code> and <code class="docutils literal notranslate">interpolations</code> attributes provide access to the string parts and any interpolations in the literal: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" template = t"Hello {name}" assert template.strings[0] == "Hello " assert template.interpolations[0].value == "World" </pre></div> </div> </section> <section id="the-interpolation-type"> <h3><a class="toc-backref" href="#the-interpolation-type" role="doc-backlink">The <code class="docutils literal notranslate">Interpolation</code> Type</a></h3> The <code class="docutils literal notranslate">Interpolation</code> type represents an expression inside a template string. Like <code class="docutils literal notranslate">Template</code>, it is a new class found in the <code class="docutils literal notranslate"><<TBD>></code> module: <div class="highlight-python notranslate"><div class="highlight"><pre>class Interpolation: value: object expr: str conv: Literal["a", "r", "s"] | None format_spec: str __match_args__ = ("value", "expr", "conv", "format_spec") def __new__( cls, value: object, expr: str, conv: Literal["a", "r", "s"] | None = None, format_spec: str = "", ): ... </pre></div> </div> The <code class="docutils literal notranslate">Interpolation</code> type is shallow immutable. Its attributes cannot be reassigned. The <code class="docutils literal notranslate">value</code> attribute is the evaluated result of the interpolation: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" template = t"Hello {name}" assert template.interpolations[0].value == "World" </pre></div> </div> The <code class="docutils literal notranslate">expr</code> attribute is the original text of the interpolation: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" template = t"Hello {name}" assert template.interpolations[0].expr == "name" </pre></div> </div> We expect that the <code class="docutils literal notranslate">expr</code> attribute will not be used in most template processing code. It is provided for completeness and for use in debugging and introspection. See both the <a class="reference internal" href="#common-patterns-seen-in-processing-templates">Common Patterns Seen in Processing Templates</a> section and the <a class="reference internal" href="#examples">Examples</a> section for more information on how to process template strings. The <code class="docutils literal notranslate">conv</code> attribute is the <a class="reference external" href="https://docs.python.org/3/library/string.html#formatstrings" title="(in Python v3.13)">optional conversion</a> to be used, one of <code class="docutils literal notranslate">r</code>, <code class="docutils literal notranslate">s</code>, and <code class="docutils literal notranslate">a</code>, corresponding to <code class="docutils literal notranslate">repr()</code>, <code class="docutils literal notranslate">str()</code>, and <code class="docutils literal notranslate">ascii()</code> conversions. As with f-strings, no other conversions are supported: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" template = t"Hello {name!r}" assert template.interpolations[0].conv == "r" </pre></div> </div> If no conversion is provided, <code class="docutils literal notranslate">conv</code> is <code class="docutils literal notranslate">None</code>. The <code class="docutils literal notranslate">format_spec</code> attribute is the <a class="reference external" href="https://docs.python.org/3/library/string.html#formatspec" title="(in Python v3.13)">format specification</a>. As with f-strings, this is an arbitrary string that defines how to present the value: <div class="highlight-python notranslate"><div class="highlight"><pre>value = 42 template = t"Value: {value:.2f}" assert template.interpolations[0].format_spec == ".2f" </pre></div> </div> Format specifications in f-strings can themselves contain interpolations. This is permitted in template strings as well; <code class="docutils literal notranslate">format_spec</code> is set to the eagerly evaluated result: <div class="highlight-python notranslate"><div class="highlight"><pre>value = 42 precision = 2 template = t"Value: {value:.{precision}f}" assert template.interpolations[0].format_spec == ".2f" </pre></div> </div> If no format specification is provided, <code class="docutils literal notranslate">format_spec</code> defaults to an empty string (<code class="docutils literal notranslate">""</code>). This matches the <code class="docutils literal notranslate">format_spec</code> parameter of Python’s <a class="reference external" href="https://docs.python.org/3/library/functions.html#format" title="(in Python v3.13)"><code class="docutils literal notranslate">format()</code></a> built-in. Unlike f-strings, it is up to code that processes the template to determine how to interpret the <code class="docutils literal notranslate">conv</code> and <code class="docutils literal notranslate">format_spec</code> attributes. Such code is not required to use these attributes, but when present they should be respected, and to the extent possible match the behavior of f-strings. It would be surprising if, for example, a template string that uses <code class="docutils literal notranslate">{value:.2f}</code> did not round the value to two decimal places when processed. </section> <section id="convenience-accessors-in-template"> <h3><a class="toc-backref" href="#convenience-accessors-in-template" role="doc-backlink">Convenience Accessors in <code class="docutils literal notranslate">Template</code></a></h3> The <code class="docutils literal notranslate">Template.values</code> property is equivalent to: <div class="highlight-python notranslate"><div class="highlight"><pre>@property def values(self) -> tuple[object, ...]: return tuple(i.value for i in self.interpolations) </pre></div> </div> The <code class="docutils literal notranslate">Template.__iter__()</code> method is equivalent to: <div class="highlight-python notranslate"><div class="highlight"><pre>def __iter__(self) -> Iterator[str | Interpolation]: for s, i in zip_longest(self.strings, self.interpolations): if s: yield s if i: yield i </pre></div> </div> </section> <section id="processing-template-strings"> <h3><a class="toc-backref" href="#processing-template-strings" role="doc-backlink">Processing Template Strings</a></h3> Developers can write arbitrary code to process template strings. For example, the following function renders static parts of the template in lowercase and interpolations in uppercase: <div class="highlight-python notranslate"><div class="highlight"><pre>from TBD import Template, Interpolation def lower_upper(template: Template) -> str: """Render static parts lowercased and interpolations uppercased.""" parts: list[str] = [] for item in template: if isinstance(item, Interpolation): parts.append(str(item.value).upper()) else: parts.append(item.lower()) return "".join(parts) name = "world" assert lower_upper(t"HELLO {name}") == "hello WORLD" </pre></div> </div> There is no requirement that template strings are processed in any particular way. Code that processes templates has no obligation to return a string. Template strings are a flexible, general-purpose feature. See the <a class="reference internal" href="#common-patterns-seen-in-processing-templates">Common Patterns Seen in Processing Templates</a> section for more information on how to process template strings. See the <a class="reference internal" href="#examples">Examples</a> section for detailed working examples. </section> <section id="template-string-concatenation"> <h3><a class="toc-backref" href="#template-string-concatenation" role="doc-backlink">Template String Concatenation</a></h3> Template strings support explicit concatenation using <code class="docutils literal notranslate">+</code>. Concatenation is supported for two <code class="docutils literal notranslate">Template</code> instances as well as for a <code class="docutils literal notranslate">Template</code> instance and a <code class="docutils literal notranslate">str</code>: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" template = t"{name}" assert isinstance(t"Hello " + template, Template) assert (t"Hello " + template).strings == ("Hello ", "") assert (t"Hello " + template).interpolations[0].value == "World" assert isinstance("Hello " + template, Template) assert ("Hello " + template).strings == ("Hello ", "") assert ("Hello " + template).interpolations[0].value == "World" </pre></div> </div> Concatenation of templates is “viral”: the concatenation of a <code class="docutils literal notranslate">Template</code> and a <code class="docutils literal notranslate">str</code> always results in a <code class="docutils literal notranslate">Template</code> instance. Python’s implicit concatenation syntax is also supported. The following code will work as expected: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" assert (t"Hello " t"World").strings == ("Hello World",) assert ("Hello " t"World").strings == ("Hello World",) </pre></div> </div> The <code class="docutils literal notranslate">Template</code> type supports the <code class="docutils literal notranslate">__add__()</code> and <code class="docutils literal notranslate">__radd__()</code> methods between two <code class="docutils literal notranslate">Template</code> instances and between a <code class="docutils literal notranslate">Template</code> instance and a <code class="docutils literal notranslate">str</code>. </section> <section id="template-and-interpolation-equality"> <h3><a class="toc-backref" href="#template-and-interpolation-equality" role="doc-backlink">Template and Interpolation Equality</a></h3> <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> instances compare with object identity (<code class="docutils literal notranslate">is</code>). <code class="docutils literal notranslate">Template</code> instances are intended to be used by template processing code, which may return a string or any other type. Those types can provide their own equality semantics as needed. </section> <section id="no-support-for-ordering"> <h3><a class="toc-backref" href="#no-support-for-ordering" role="doc-backlink">No Support for Ordering</a></h3> The <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> types do not support ordering. This is unlike all other string literal types in Python, which support lexicographic ordering. Because interpolations can contain arbitrary values, there is no natural ordering for them. As a result, neither the <code class="docutils literal notranslate">Template</code> nor the <code class="docutils literal notranslate">Interpolation</code> type implements the standard comparison methods. </section> <section id="support-for-the-debug-specifier"> <h3><a class="toc-backref" href="#support-for-the-debug-specifier" role="doc-backlink">Support for the debug specifier (<code class="docutils literal notranslate">=</code>)</a></h3> The debug specifier, <code class="docutils literal notranslate">=</code>, is supported in template strings and behaves similarly to how it behaves in f-strings, though due to limitations of the implementation there is a slight difference. In particular, <code class="docutils literal notranslate">t'{expr=}'</code> is treated as <code class="docutils literal notranslate">t'expr={expr!r}'</code>: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" template = t"Hello {name=}" assert template.strings[0] == "Hello name=" assert template.interpolations[0].value == "World" assert template.interpolations[0].conv == "r" </pre></div> </div> If a separate format string is also provided, <code class="docutils literal notranslate">t'{expr=:fmt}</code> is treated instead as <code class="docutils literal notranslate">t'expr={expr!s:fmt}'</code>. Whitespace is preserved in the debug specifier, so <code class="docutils literal notranslate">t'{expr = }'</code> is treated as <code class="docutils literal notranslate">t'expr = {expr!r}'</code>. </section> <section id="raw-template-strings"> <h3><a class="toc-backref" href="#raw-template-strings" role="doc-backlink">Raw Template Strings</a></h3> Raw template strings are supported using the <code class="docutils literal notranslate">rt</code> (or <code class="docutils literal notranslate">tr</code>) prefix: <div class="highlight-python notranslate"><div class="highlight"><pre>trade = 'shrubberies' template = rt'Did you say "{trade}"?\n' assert template.strings[0] == r'Did you say "' assert template.strings[1] == r'"?\n' </pre></div> </div> In this example, the <code class="docutils literal notranslate">\n</code> is treated as two separate characters (a backslash followed by ‘n’) rather than a newline character. This is consistent with Python’s raw string behavior. As with regular template strings, interpolations in raw template strings are processed normally, allowing for the combination of raw string behavior and dynamic content. </section> <section id="interpolation-expression-evaluation"> <h3><a class="toc-backref" href="#interpolation-expression-evaluation" role="doc-backlink">Interpolation Expression Evaluation</a></h3> Expression evaluation for interpolations is the same as in <a class="pep reference internal" href="../pep-0498/#expression-evaluation" title="PEP 498 – Literal String Interpolation § Expression evaluation">PEP 498</a>: <blockquote> <div>The expressions that are extracted from the string are evaluated in the context where the template string appeared. This means the expression has full access to its lexical scope, including local and global variables. Any valid Python expression can be used, including function and method calls.</div></blockquote> Template strings are evaluated eagerly from left to right, just like f-strings. This means that interpolations are evaluated immediately when the template string is processed, not deferred or wrapped in lambdas. </section> <section id="exceptions"> <h3><a class="toc-backref" href="#exceptions" role="doc-backlink">Exceptions</a></h3> Exceptions raised in t-string literals are the same as those raised in f-string literals. </section> <section id="no-template-str-implementation"> <h3><a class="toc-backref" href="#no-template-str-implementation" role="doc-backlink">No <code class="docutils literal notranslate">Template.__str__()</code> Implementation</a></h3> The <code class="docutils literal notranslate">Template</code> type does not provide a specialized <code class="docutils literal notranslate">__str__()</code> implementation. This is because <code class="docutils literal notranslate">Template</code> instances are intended to be used by template processing code, which may return a string or any other type. There is no canonical way to convert a Template to a string. The <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> types both provide useful <code class="docutils literal notranslate">__repr__()</code> implementations. </section> </section> <section id="examples"> <h2><a class="toc-backref" href="#examples" role="doc-backlink">Examples</a></h2> All examples in this section of the PEP have fully tested reference implementations available in the public <a class="reference external" href="https://github.com/davepeck/pep750-examples">pep750-examples</a> git repository. <section id="example-implementing-f-strings-with-t-strings"> <h3><a class="toc-backref" href="#example-implementing-f-strings-with-t-strings" role="doc-backlink">Example: Implementing f-strings with t-strings</a></h3> It is easy to “implement” f-strings using t-strings. That is, we can write a function <code class="docutils literal notranslate">f(template: Template) -> str</code> that processes a <code class="docutils literal notranslate">Template</code> in much the same way as an f-string literal, returning the same result: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" value = 42 templated = t"Hello {name!r}, value: {value:.2f}" formatted = f"Hello {name!r}, value: {value:.2f}" assert f(templated) == formatted </pre></div> </div> The <code class="docutils literal notranslate">f()</code> function supports both conversion specifiers like <code class="docutils literal notranslate">!r</code> and format specifiers like <code class="docutils literal notranslate">:.2f</code>. The full code is fairly simple: <div class="highlight-python notranslate"><div class="highlight"><pre>from TBD import Template, Interpolation def convert(value: object, conv: Literal["a", "r", "s"] | None) -> object: if conv == "a": return ascii(value) elif conv == "r": return repr(value) elif conv == "s": return str(value) return value def f(template: Template) -> str: parts = [] for item in template: match item: case str() as s: parts.append(s) case Interpolation(value, _, conv, format_spec): value = convert(value, conv) value = format(value, format_spec) parts.append(value) return "".join(parts) </pre></div> </div> <div class="admonition note"> Note Example code See <a class="reference external" href="https://github.com/davepeck/pep750-examples/blob/main/pep/fstring.py">fstring.py</a> and <a class="reference external" href="https://github.com/davepeck/pep750-examples/blob/main/pep/test_fstring.py">test_fstring.py</a>. </div> </section> <section id="example-structured-logging"> <h3><a class="toc-backref" href="#example-structured-logging" role="doc-backlink">Example: Structured Logging</a></h3> Structured logging allows developers to log data in machine-readable formats like JSON. With t-strings, developers can easily log structured data alongside human-readable messages using just a single log statement. We present two different approaches to implementing structured logging with template strings. <section id="approach-1-custom-log-messages"> <h4><a class="toc-backref" href="#approach-1-custom-log-messages" role="doc-backlink">Approach 1: Custom Log Messages</a></h4> The <a class="reference external" href="https://docs.python.org/3/howto/logging-cookbook.html#logging-cookbook" title="(in Python v3.13)">Python Logging Cookbook</a> has a short section on <a class="reference external" href="https://docs.python.org/3/howto/logging-cookbook.html#implementing-structured-logging">how to implement structured logging</a>. The logging cookbook suggests creating a new “message” class, <code class="docutils literal notranslate">StructuredMessage</code>, that is constructed with a simple text message and a separate dictionary of values: <div class="highlight-python notranslate"><div class="highlight"><pre>message = StructuredMessage("user action", { "action": "traded", "amount": 42, "item": "shrubs" }) logging.info(message) # Outputs: # user action >>> {"action": "traded", "amount": 42, "item": "shrubs"} </pre></div> </div> The <code class="docutils literal notranslate">StructuredMessage.__str__()</code> method formats both the human-readable message and the values, combining them into a final string. (See the <a class="reference external" href="https://docs.python.org/3/howto/logging-cookbook.html#implementing-structured-logging">logging cookbook</a> for its full example.) We can implement an improved version of <code class="docutils literal notranslate">StructuredMessage</code> using template strings: <div class="highlight-python notranslate"><div class="highlight"><pre>import json from TBD import Interpolation, Template from typing import Mapping class TemplateMessage: def __init__(self, template: Template) -> None: self.template = template @property def message(self) -> str: # Use the f() function from the previous example return f(self.template) @property def values(self) -> Mapping[str, object]: return { item.expr: item.value for item in self.template if isinstance(item, Interpolation) } def __str__(self) -> str: return f"{self.message} >>> {json.dumps(self.values)}" _ = TemplateMessage # optional, to improve readability action, amount, item = "traded", 42, "shrubs" logging.info(_(t"User {action}: {amount:.2f} {item}")) # Outputs: # User traded: 42.00 shrubs >>> {"action": "traded", "amount": 42, "item": "shrubs"} </pre></div> </div> Template strings give us a more elegant way to define the custom message class. With template strings it is no longer necessary for developers to make sure that their format string and values dictionary are kept in sync; a single template string literal is all that is needed. The <code class="docutils literal notranslate">TemplateMessage</code> implementation can automatically extract structured keys and values from the <code class="docutils literal notranslate">Interpolation.expr</code> and <code class="docutils literal notranslate">Interpolation.value</code> attributes, respectively. </section> <section id="approach-2-custom-formatters"> <h4><a class="toc-backref" href="#approach-2-custom-formatters" role="doc-backlink">Approach 2: Custom Formatters</a></h4> Custom messages are a reasonable approach to structured logging but can be a little awkward. To use them, developers must wrap every log message they write in a custom class. This can be easy to forget. An alternative approach is to define custom <code class="docutils literal notranslate">logging.Formatter</code> classes. This approach is more flexible and allows for more control over the final output. In particular, it’s possible to take a single template string and output it in multiple formats (human-readable and JSON) to separate log streams. We define two simple formatters, a <code class="docutils literal notranslate">MessageFormatter</code> for human-readable output and a <code class="docutils literal notranslate">ValuesFormatter</code> for JSON output: <div class="highlight-python notranslate"><div class="highlight"><pre>import json from logging import Formatter, LogRecord from TBD import Interpolation, Template from typing import Any, Mapping class MessageFormatter(Formatter): def message(self, template: Template) -> str: # Use the f() function from the previous example return f(template) def format(self, record: LogRecord) -> str: msg = record.msg if not isinstance(msg, Template): return super().format(record) return self.message(msg) class ValuesFormatter(Formatter): def values(self, template: Template) -> Mapping[str, Any]: return { item.expr: item.value for item in template if isinstance(item, Interpolation) } def format(self, record: LogRecord) -> str: msg = record.msg if not isinstance(msg, Template): return super().format(record) return json.dumps(self.values(msg)) </pre></div> </div> We can then use these formatters when configuring our logger: <div class="highlight-python notranslate"><div class="highlight"><pre>import logging import sys logger = logging.getLogger(__name__) message_handler = logging.StreamHandler(sys.stdout) message_handler.setFormatter(MessageFormatter()) logger.addHandler(message_handler) values_handler = logging.StreamHandler(sys.stderr) values_handler.setFormatter(ValuesFormatter()) logger.addHandler(values_handler) action, amount, item = "traded", 42, "shrubs" logger.info(t"User {action}: {amount:.2f} {item}") # Outputs to sys.stdout: # User traded: 42.00 shrubs # At the same time, outputs to sys.stderr: # {"action": "traded", "amount": 42, "item": "shrubs"} </pre></div> </div> This approach has a couple advantages over the custom message approach to structured logging: <ul class="simple"> <li>Developers can log a t-string directly without wrapping it in a custom class.</li> <li>Human-readable and structured output can be sent to separate log streams. This is useful for log aggregation systems that process structured data independently from human-readable data.</li> </ul> <div class="admonition note"> Note Example code See <a class="reference external" href="https://github.com/davepeck/pep750-examples/blob/main/pep/logging.py">logging.py</a> and <a class="reference external" href="https://github.com/davepeck/pep750-examples/blob/main/pep/test_logging.py">test_logging.py</a>. </div> </section> </section> <section id="example-html-templating"> <h3><a class="toc-backref" href="#example-html-templating" role="doc-backlink">Example: HTML Templating</a></h3> This PEP contains several short HTML templating examples. It turns out that the “hypothetical” <code class="docutils literal notranslate">html()</code> function mentioned in the <a class="reference internal" href="#motivation">Motivation</a> section (and a few other places in this PEP) exists and is available in the <a class="reference external" href="https://github.com/davepeck/pep750-examples/">pep750-examples repository</a>. If you’re thinking about parsing a complex grammar with template strings, we hope you’ll find it useful. </section> </section> <section id="backwards-compatibility"> <h2><a class="toc-backref" href="#backwards-compatibility" role="doc-backlink">Backwards Compatibility</a></h2> Like f-strings, use of template strings will be a syntactic backwards incompatibility with previous versions. </section> <section id="security-implications"> <h2><a class="toc-backref" href="#security-implications" role="doc-backlink">Security Implications</a></h2> The security implications of working with template strings, with respect to interpolations, are as follows: <ol class="arabic simple"> <li>Scope lookup is the same as f-strings (lexical scope). This model has been shown to work well in practice.</li> <li>Code that processes <code class="docutils literal notranslate">Template</code> instances can ensure that any interpolations are processed in a safe fashion, including respecting the context in which they appear.</li> </ol> </section> <section id="how-to-teach-this"> <h2><a class="toc-backref" href="#how-to-teach-this" role="doc-backlink">How To Teach This</a></h2> Template strings have several audiences: <ul class="simple"> <li>Developers using template strings and processing functions</li> <li>Authors of template processing code</li> <li>Framework authors who build interesting machinery with template strings</li> </ul> We hope that teaching developers will be straightforward. At a glance, template strings look just like f-strings. Their syntax is familiar and the scoping rules remain the same. The first thing developers must learn is that template string literals don’t evaluate to strings; instead, they evaluate to a new type, <code class="docutils literal notranslate">Template</code>. This is a simple type intended to be used by template processing code. It’s not until developers call a processing function that they get the result they want: typically, a string, although processing code can of course return any arbitrary type. Developers will also want to understand how template strings relate to other string formatting methods like f-strings and <a class="reference external" href="https://docs.python.org/3/library/stdtypes.html#str.format" title="(in Python v3.13)"><code class="xref py py-meth docutils literal notranslate">str.format()</code></a>. They will need to decide when to use each method. If a simple string is all that is needed, and there are no security implications, f-strings are likely the best choice. For most cases where a format string is used, it can be replaced with a function wrapping the creation of a template string. In cases where the format string is obtained from user input, the filesystem, or databases, it is possible to write code to convert it into a <code class="docutils literal notranslate">Template</code> instance if desired. Because developers will learn that t-strings are nearly always used in tandem with processing functions, they don’t necessarily need to understand the details of the <code class="docutils literal notranslate">Template</code> type. As with descriptors and decorators, we expect many more developers will use t-strings than write t-string processing functions. Over time, a small number of more advanced developers will wish to author their own template processing code. Writing processing code often requires thinking in terms of formal grammars. Developers will need to learn how to work with the <code class="docutils literal notranslate">strings</code> and <code class="docutils literal notranslate">interpolation</code> attributes of a <code class="docutils literal notranslate">Template</code> instance and how to process interpolations in a context-sensitive fashion. More sophisticated grammars will likely require parsing to intermediate representations like an AST. Great template processing code will handle format specifiers and conversions when appropriate. Writing production-grade template processing code – for instance, to support HTML templates – can be a large undertaking. We expect that template strings will provide framework authors with a powerful new tool in their toolbox. While the functionality of template strings overlaps with existing tools like template engines, t-strings move that logic into the language itself. Bringing the full power and generality of Python to bear on string processing tasks opens new possibilities for framework authors. </section> <section id="why-another-templating-approach"> <h2><a class="toc-backref" href="#why-another-templating-approach" role="doc-backlink">Why another templating approach?</a></h2> The world of Python already has mature templating languages with wide adoption, such as Jinja. Why build support for creating new templating systems? Projects such as Jinja are still needed in cases where the template is less part of the software by the developers, and more part of customization by designers or even content created by users, for example in a CMS. The trends in frontend development have treated templating as part of the software and written by developers. They want modern language features and a good tooling experience. PEP 750 envisions DSLs where the non-static parts are Python: same scope rules, typing, expression syntax, and the like. </section> <section id="common-patterns-seen-in-processing-templates"> <h2><a class="toc-backref" href="#common-patterns-seen-in-processing-templates" role="doc-backlink">Common Patterns Seen in Processing Templates</a></h2> <section id="structural-pattern-matching"> <h3><a class="toc-backref" href="#structural-pattern-matching" role="doc-backlink">Structural Pattern Matching</a></h3> Iterating over the <code class="docutils literal notranslate">Template</code> with structural pattern matching is the expected best practice for many template function implementations: <div class="highlight-python notranslate"><div class="highlight"><pre>from TBD import Template, Interpolation def process(template: Template) -> Any: for item in template: match item: case str() as s: ... # handle each string part case Interpolation() as interpolation: ... # handle each interpolation </pre></div> </div> Processing code may also commonly sub-match on attributes of the <code class="docutils literal notranslate">Interpolation</code> type: <div class="highlight-python notranslate"><div class="highlight"><pre>match arg: case Interpolation(int()): ... # handle interpolations with integer values case Interpolation(value=str() as s): ... # handle interpolations with string values # etc. </pre></div> </div> </section> <section id="memoizing"> <h3><a class="toc-backref" href="#memoizing" role="doc-backlink">Memoizing</a></h3> Template functions can efficiently process both static and dynamic parts of templates. The structure of <code class="docutils literal notranslate">Template</code> objects allows for effective memoization: <div class="highlight-python notranslate"><div class="highlight"><pre>strings = template.strings # Static string parts values = template.values # Dynamic interpolated values </pre></div> </div> This separation enables caching of processed static parts while dynamic parts can be inserted as needed. Authors of template processing code can use the static <code class="docutils literal notranslate">strings</code> as cache keys, leading to significant performance improvements when similar templates are used repeatedly. </section> <section id="parsing-to-intermediate-representations"> <h3><a class="toc-backref" href="#parsing-to-intermediate-representations" role="doc-backlink">Parsing to Intermediate Representations</a></h3> Code that processes templates can parse the template string into intermediate representations, like an AST. We expect that many template processing libraries will use this approach. For instance, rather than returning a <code class="docutils literal notranslate">str</code>, our theoretical <code class="docutils literal notranslate">html()</code> function (see the <a class="reference internal" href="#motivation">Motivation</a> section) could return an HTML <code class="docutils literal notranslate">Element</code> defined in the same package: <div class="highlight-python notranslate"><div class="highlight"><pre>@dataclass(frozen=True) class Element: tag: str attributes: Mapping[str, str | bool] children: Sequence[str | Element] def __str__(self) -> str: ... def html(template: Template) -> Element: ... </pre></div> </div> Calling <code class="docutils literal notranslate">str(element)</code> would then render the HTML but, in the meantime, the <code class="docutils literal notranslate">Element</code> could be manipulated in a variety of ways. </section> <section id="context-sensitive-processing-of-interpolations"> <h3><a class="toc-backref" href="#context-sensitive-processing-of-interpolations" role="doc-backlink">Context-sensitive Processing of Interpolations</a></h3> Continuing with our hypothetical <code class="docutils literal notranslate">html()</code> function, it could be made context-sensitive. Interpolations could be processed differently depending on where they appear in the template. For example, our <code class="docutils literal notranslate">html()</code> function could support multiple kinds of interpolations: <div class="highlight-python notranslate"><div class="highlight"><pre>attributes = {"id": "main"} attribute_value = "shrubbery" content = "hello" template = t"<div {attributes} data-value={attribute_value}>{content}</div>" element = html(template) assert str(element) == '<div id="main" data-value="shrubbery">hello</div>' </pre></div> </div> Because the <code class="docutils literal notranslate">{attributes}</code> interpolation occurs in the context of an HTML tag, and because there is no corresponding attribute name, it is treated as a dictionary of attributes. The <code class="docutils literal notranslate">{attribute_value}</code> interpolation is treated as a simple string value and is quoted before inclusion in the final string. The <code class="docutils literal notranslate">{content}</code> interpolation is treated as potentially unsafe content and is escaped before inclusion in the final string. </section> <section id="nested-template-strings"> <h3><a class="toc-backref" href="#nested-template-strings" role="doc-backlink">Nested Template Strings</a></h3> Going a step further with our <code class="docutils literal notranslate">html()</code> function, we could support nested template strings. This would allow for more complex HTML structures to be built up from simpler templates: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" content = html(t"Hello {name}") template = t"<div>{content}</div>" element = html(template) assert str(element) == '<div>Hello World</div>' </pre></div> </div> Because the <code class="docutils literal notranslate">{content}</code> interpolation is an <code class="docutils literal notranslate">Element</code> instance, it does not need to be escaped before inclusion in the final string. One could imagine a nice simplification: if the <code class="docutils literal notranslate">html()</code> function is passed a <code class="docutils literal notranslate">Template</code> instance, it could automatically convert it to an <code class="docutils literal notranslate">Element</code> by recursively calling itself on the nested template. We expect that nesting and composition of templates will be a common pattern in template processing code and, where appropriate, used in preference to simple string concatenation. </section> <section id="approaches-to-lazy-evaluation"> <h3><a class="toc-backref" href="#approaches-to-lazy-evaluation" role="doc-backlink">Approaches to Lazy Evaluation</a></h3> Like f-strings, interpolations in t-string literals are eagerly evaluated. However, there are cases where lazy evaluation may be desirable. If a single interpolation is expensive to evaluate, it can be explicitly wrapped in a <code class="docutils literal notranslate">lambda</code> in the template string literal: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" template = t"Hello {(lambda: name)}" assert callable(template.interpolations[0].value) assert template.interpolations[0].value() == "World" </pre></div> </div> This assumes, of course, that template processing code anticipates and handles callable interpolation values. (One could imagine also supporting iterators, awaitables, etc.) This is not a requirement of the PEP, but it is a common pattern in template processing code. In general, we hope that the community will develop best practices for lazy evaluation of interpolations in template strings and that, when it makes sense, common libraries will provide support for callable or awaitable values in their template processing code. </section> <section id="approaches-to-asynchronous-evaluation"> <h3><a class="toc-backref" href="#approaches-to-asynchronous-evaluation" role="doc-backlink">Approaches to Asynchronous Evaluation</a></h3> Closely related to lazy evaluation is asynchronous evaluation. As with f-strings, the <code class="docutils literal notranslate">await</code> keyword is allowed in interpolations: <div class="highlight-python notranslate"><div class="highlight"><pre>async def example(): async def get_name() -> str: await asyncio.sleep(1) return "Sleepy" template = t"Hello {await get_name()}" # Use the f() function from the f-string example, above assert f(template) == "Hello Sleepy" </pre></div> </div> More sophisticated template processing code can take advantage of this to perform asynchronous operations in interpolations. For example, a “smart” processing function could anticipate that an interpolation is an awaitable and await it before processing the template string: <div class="highlight-python notranslate"><div class="highlight"><pre>async def example(): async def get_name() -> str: await asyncio.sleep(1) return "Sleepy" template = t"Hello {get_name}" assert await async_f(template) == "Hello Sleepy" </pre></div> </div> This assumes that the template processing code in <code class="docutils literal notranslate">async_f()</code> is asynchronous and is able to <code class="docutils literal notranslate">await</code> an interpolation’s value. <div class="admonition note"> Note Example code See <a class="reference external" href="https://github.com/davepeck/pep750-examples/blob/main/pep/afstring.py">afstring.py</a> and <a class="reference external" href="https://github.com/davepeck/pep750-examples/blob/main/pep/test_afstring.py">test_afstring.py</a>. </div> </section> <section id="approaches-to-template-reuse"> <h3><a class="toc-backref" href="#approaches-to-template-reuse" role="doc-backlink">Approaches to Template Reuse</a></h3> If developers wish to reuse template strings multiple times with different values, they can write a function to return a <code class="docutils literal notranslate">Template</code> instance: <div class="highlight-python notranslate"><div class="highlight"><pre>def reusable(name: str, question: str) -> Template: return t"Hello {name}, {question}?" template = reusable("friend", "how are you") template = reusable("King Arthur", "what is your quest") </pre></div> </div> This is, of course, no different from how f-strings can be reused. </section> <section id="relation-to-format-strings"> <h3><a class="toc-backref" href="#relation-to-format-strings" role="doc-backlink">Relation to Format Strings</a></h3> The venerable <a class="reference external" href="https://docs.python.org/3/library/stdtypes.html#str.format" title="(in Python v3.13)"><code class="xref py py-meth docutils literal notranslate">str.format()</code></a> method accepts format strings that can later be used to format values: <div class="highlight-python notranslate"><div class="highlight"><pre>alas_fmt = "We're all out of {cheese}." assert alas_fmt.format(cheese="Red Leicester") == "We're all out of Red Leicester." </pre></div> </div> If one squints, one can think of format strings as a kind of function definition. The call to <a class="reference external" href="https://docs.python.org/3/library/stdtypes.html#str.format" title="(in Python v3.13)"><code class="xref py py-meth docutils literal notranslate">str.format()</code></a> can be seen as a kind of function call. The t-string equivalent is to simply define a standard Python function that returns a <code class="docutils literal notranslate">Template</code> instance: <div class="highlight-python notranslate"><div class="highlight"><pre>def make_template(*, cheese: str) -> Template: return t"We're all out of {cheese}." template = make_template(cheese="Red Leicester") # Using the f() function from the f-string example, above assert f(template) == "We're all out of Red Leicester." </pre></div> </div> The <code class="docutils literal notranslate">make_template()</code> function itself can be thought of as analogous to the format string. The call to <code class="docutils literal notranslate">make_template()</code> is analogous to the call to <a class="reference external" href="https://docs.python.org/3/library/stdtypes.html#str.format" title="(in Python v3.13)"><code class="xref py py-meth docutils literal notranslate">str.format()</code></a>. Of course, it is common to load format strings from external sources like a filesystem or database. Thankfully, because <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> are simple Python types, it is possible to write a function that takes an old-style format string and returns an equivalent <code class="docutils literal notranslate">Template</code> instance: <div class="highlight-python notranslate"><div class="highlight"><pre>def from_format(fmt: str, /, *args: object, **kwargs: object) -> Template: """Parse `fmt` and return a `Template` instance.""" ... # Load this from a file, database, etc. fmt = "We're all out of {cheese}." template = from_format(fmt, cheese="Red Leicester") # Using the f() function from the f-string example, above assert f(template) == "We're all out of Red Leicester." </pre></div> </div> This is a powerful pattern that allows developers to use template strings in places where they might have previously used format strings. A full implementation of <code class="docutils literal notranslate">from_format()</code> is available in the examples repository, which supports the full grammar of format strings. <div class="admonition note"> Note Example code See <a class="reference external" href="https://github.com/davepeck/pep750-examples/blob/main/pep/format.py">format.py</a> and <a class="reference external" href="https://github.com/davepeck/pep750-examples/blob/main/pep/test_format.py">test_format.py</a>. </div> </section> </section> <section id="reference-implementation"> <h2><a class="toc-backref" href="#reference-implementation" role="doc-backlink">Reference Implementation</a></h2> A CPython implementation of PEP 750 is <a class="reference external" href="https://github.com/lysnikolaou/cpython/tree/tstrings">available</a>. There is also a public repository of <a class="reference external" href="https://github.com/davepeck/pep750-examples">examples and tests</a> built around the reference implementation. If you’re interested in playing with template strings, this repository is a great place to start. </section> <section id="rejected-ideas"> <h2><a class="toc-backref" href="#rejected-ideas" role="doc-backlink">Rejected Ideas</a></h2> This PEP has been through several significant revisions. In addition, quite a few interesting ideas were considered both in revisions of <a class="pep reference internal" href="../pep-0501/" title="PEP 501 – General purpose template literal strings">PEP 501</a> and in the <a class="reference external" href="https://discuss.python.org/t/pep-750-tag-strings-for-writing-domain-specific-languages/60408/196">Discourse discussion</a>. We attempt to document the most significant ideas that were considered and rejected. <section id="arbitrary-string-literal-prefixes"> <h3><a class="toc-backref" href="#arbitrary-string-literal-prefixes" role="doc-backlink">Arbitrary String Literal Prefixes</a></h3> Inspired by <a class="reference external" href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates">JavaScript tagged template literals</a>, an earlier version of this PEP allowed for arbitrary “tag” prefixes in front of literal strings: <div class="highlight-python notranslate"><div class="highlight"><pre>my_tag'Hello {name}' </pre></div> </div> The prefix was a special callable called a “tag function”. Tag functions received the parts of the template string in an argument list. They could then process the string and return an arbitrary value: <div class="highlight-python notranslate"><div class="highlight"><pre>def my_tag(*args: str | Interpolation) -> Any: ... </pre></div> </div> This approach was rejected for several reasons: <ul class="simple"> <li>It was deemed too complex to build in full generality. JavaScript allows for arbitrary expressions to precede a template string, which is a significant challenge to implement in Python.</li> <li>It precluded future introduction of new string prefixes.</li> <li>It seemed to needlessly pollute the namespace.</li> </ul> Use of a single <code class="docutils literal notranslate">t</code> prefix was chosen as a simpler, more Pythonic approach and more in keeping with template strings’ role as a generalization of f-strings. </section> <section id="delayed-evaluation-of-interpolations"> <h3><a class="toc-backref" href="#delayed-evaluation-of-interpolations" role="doc-backlink">Delayed Evaluation of Interpolations</a></h3> An early version of this PEP proposed that interpolations should be lazily evaluated. All interpolations were “wrapped” in implicit lambdas. Instead of having an eagerly evaluated <code class="docutils literal notranslate">value</code> attribute, interpolations had a <code class="docutils literal notranslate">getvalue()</code> method that would resolve the value of the interpolation: <div class="highlight-python notranslate"><div class="highlight"><pre>class Interpolation: ... _value: Callable[[], object] def getvalue(self) -> object: return self._value() </pre></div> </div> This was rejected for several reasons: <ul class="simple"> <li>The overwhelming majority of use cases for template strings naturally call for immediate evaluation.</li> <li>Delayed evaluation would be a significant departure from the behavior of f-strings.</li> <li>Implicit lambda wrapping leads to difficulties with type hints and static analysis.</li> </ul> Most importantly, there are viable (if imperfect) alternatives to implicit lambda wrapping in many cases where lazy evaluation is desired. See the section on <a class="reference internal" href="#approaches-to-lazy-evaluation">Approaches to Lazy Evaluation</a>, above, for more information. While delayed evaluation was rejected for this PEP, we hope that the community continues to explore the idea. </section> <section id="making-template-and-interpolation-into-protocols"> <h3><a class="toc-backref" href="#making-template-and-interpolation-into-protocols" role="doc-backlink">Making <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> Into Protocols</a></h3> An early version of this PEP proposed that the <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> types be runtime checkable protocols rather than classes. In the end, we felt that using classes was more straightforward. </section> <section id="overridden-eq-and-hash-for-template-and-interpolation"> <h3><a class="toc-backref" href="#overridden-eq-and-hash-for-template-and-interpolation" role="doc-backlink">Overridden <code class="docutils literal notranslate">__eq__</code> and <code class="docutils literal notranslate">__hash__</code> for <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code></a></h3> Earlier versions of this PEP proposed that the <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> types should have their own implementations of <code class="docutils literal notranslate">__eq__</code> and <code class="docutils literal notranslate">__hash__</code>. <code class="docutils literal notranslate">Templates</code> were considered equal if their <code class="docutils literal notranslate">strings</code> and <code class="docutils literal notranslate">interpolations</code> were equal; <code class="docutils literal notranslate">Interpolations</code> were considered equal if their <code class="docutils literal notranslate">value</code>, <code class="docutils literal notranslate">expr</code>, <code class="docutils literal notranslate">conv</code>, and <code class="docutils literal notranslate">format_spec</code> were equal. Interpolation hashing was similar to tuple hashing: an <code class="docutils literal notranslate">Interpolation</code> was hashable if and only if its <code class="docutils literal notranslate">value</code> was hashable. This was rejected because <code class="docutils literal notranslate">Template.__hash__</code> so defined was not useful as a cache key in template processing code; we were concerned that it would be confusing to developers. By dropping these implementations of <code class="docutils literal notranslate">__eq__</code> and <code class="docutils literal notranslate">__hash__</code>, we lose the ability to write asserts such as: <div class="highlight-python notranslate"><div class="highlight"><pre>name = "World" assert t"Hello " + t"{name}" == t"Hello {name}" </pre></div> </div> Because <code class="docutils literal notranslate">Template</code> instances are intended to be quickly processed by further code, we felt that the utility of these asserts was limited. </section> <section id="an-additional-decoded-type"> <h3><a class="toc-backref" href="#an-additional-decoded-type" role="doc-backlink">An Additional <code class="docutils literal notranslate">Decoded</code> Type</a></h3> An early version of this PEP proposed an additional type, <code class="docutils literal notranslate">Decoded</code>, to represent the “static string” parts of a template string. This type derived from <code class="docutils literal notranslate">str</code> and had a single extra <code class="docutils literal notranslate">raw</code> attribute that provided the original text of the string. We rejected this in favor of the simpler approach of using plain <code class="docutils literal notranslate">str</code> and allowing combination of <code class="docutils literal notranslate">r</code> and <code class="docutils literal notranslate">t</code> prefixes. </section> <section id="the-final-home-for-template-and-interpolation"> <h3><a class="toc-backref" href="#the-final-home-for-template-and-interpolation" role="doc-backlink">The Final Home for <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code></a></h3> Previous versions of this PEP proposed placing the <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> types in: <code class="docutils literal notranslate">types</code>, <code class="docutils literal notranslate">collections</code>, <code class="docutils literal notranslate">collections.abc</code>, and even in a new top-level module, <code class="docutils literal notranslate">templatelib</code>. As of this writing, no core team consensus has emerged on the final location for these types. The current PEP leaves this open for a final decision. One argument in favor of a new top-level <code class="docutils literal notranslate">templatelib</code> module is that it would allow for future addition of related methods (like <code class="docutils literal notranslate">convert()</code>) and for potential future template processing code to be added to submodules (<code class="docutils literal notranslate">templatelib.shell</code>, etc.). </section> <section id="enable-full-reconstruction-of-original-template-literal"> <h3><a class="toc-backref" href="#enable-full-reconstruction-of-original-template-literal" role="doc-backlink">Enable Full Reconstruction of Original Template Literal</a></h3> Earlier versions of this PEP attempted to make it possible to fully reconstruct the text of the original template string from a <code class="docutils literal notranslate">Template</code> instance. This was rejected as being overly complex. There are several limitations with respect to round-tripping to the original source text: <ul class="simple"> <li><code class="docutils literal notranslate">Interpolation.format_spec</code> defaults to <code class="docutils literal notranslate">""</code> if not provided. It is therefore impossible to distinguish <code class="docutils literal notranslate">t"{expr}"</code> from <code class="docutils literal notranslate">t"{expr:}"</code>.</li> <li>The debug specifier, <code class="docutils literal notranslate">=</code>, is treated as a special case. It is therefore not possible to distinguish <code class="docutils literal notranslate">t"{expr=}"</code> from <code class="docutils literal notranslate">t"expr={expr}"</code>.</li> <li>Finally, format specifiers in f-strings allow arbitrary nesting. In this PEP and in the reference implementation, the specifier is eagerly evaluated to set the <code class="docutils literal notranslate">format_spec</code> in the <code class="docutils literal notranslate">Interpolation</code>, thereby losing the original expressions. For example:</li> </ul> <div class="highlight-python notranslate"><div class="highlight"><pre>value = 42 precision = 2 template = t"Value: {value:.{precision}f}" assert template.interpolations[0].format_spec == ".2f" </pre></div> </div> We do not anticipate that these limitations will be a significant issue in practice. Developers who need to obtain the original template string literal can always use <code class="docutils literal notranslate">inspect.getsource()</code> or similar tools. </section> <section id="disallowing-string-concatenation"> <h3><a class="toc-backref" href="#disallowing-string-concatenation" role="doc-backlink">Disallowing String Concatenation</a></h3> Earlier versions of this PEP proposed that template strings should not support concatenation. This was rejected in favor of allowing concatenation. There are reasonable arguments in favor of rejecting one or all forms of concatenation: namely, that it cuts off a class of potential bugs, particularly when one takes the view that template strings will often contain complex grammars for which concatenation doesn’t always have the same meaning (or any meaning). Moreover, the earliest versions of this PEP proposed a syntax closer to JavaScript’s tagged template literals, where an arbitrary callable could be used as a prefix to a string literal. There was no guarantee that the callable would return a type that supported concatenation. In the end, we decided that the surprise to developers of a new string type not supporting concatenation was likely to be greater than the theoretical harm caused by supporting it. (Developers concatenate f-strings all the time, after all, and while we are sure there are cases where this introduces bugs, it’s not clear that those bugs outweigh the benefits of supporting concatenation.) While concatenation is supported, we expect that code that uses template strings will more commonly build up larger templates through nesting and composition rather than concatenation. </section> <section id="arbitrary-conversion-values"> <h3><a class="toc-backref" href="#arbitrary-conversion-values" role="doc-backlink">Arbitrary Conversion Values</a></h3> Python allows only <code class="docutils literal notranslate">r</code>, <code class="docutils literal notranslate">s</code>, or <code class="docutils literal notranslate">a</code> as possible conversion type values. Trying to assign a different value results in <code class="docutils literal notranslate">SyntaxError</code>. In theory, template functions could choose to handle other conversion types. But this PEP adheres closely to <a class="pep reference internal" href="../pep-0701/" title="PEP 701 – Syntactic formalization of f-strings">PEP 701</a>. Any changes to allowed values should be in a separate PEP. </section> <section id="removing-conv-from-interpolation"> <h3><a class="toc-backref" href="#removing-conv-from-interpolation" role="doc-backlink">Removing <code class="docutils literal notranslate">conv</code> From <code class="docutils literal notranslate">Interpolation</code></a></h3> During the authoring of this PEP, we considered removing the <code class="docutils literal notranslate">conv</code> attribute from <code class="docutils literal notranslate">Interpolation</code> and specifying that the conversion should be performed eagerly, before <code class="docutils literal notranslate">Interpolation.value</code> is set. This was done to simplify the work of writing template processing code. The <code class="docutils literal notranslate">conv</code> attribute is of limited extensibility (it is typed as <code class="docutils literal notranslate">Literal["r", "s", "a"] | None</code>). It is not clear that it adds significant value or flexibility to template strings that couldn’t better be achieved with custom format specifiers. Unlike with format specifiers, there is no equivalent to Python’s <a class="reference external" href="https://docs.python.org/3/library/functions.html#format" title="(in Python v3.13)"><code class="docutils literal notranslate">format()</code></a> built-in. (Instead, we include an sample implementation of <code class="docutils literal notranslate">convert()</code> in the <a class="reference internal" href="#examples">Examples</a> section.) Ultimately we decided to keep the <code class="docutils literal notranslate">conv</code> attribute in the <code class="docutils literal notranslate">Interpolation</code> type to maintain compatibility with f-strings and to allow for future extensibility. </section> <section id="alternate-interpolation-symbols"> <h3><a class="toc-backref" href="#alternate-interpolation-symbols" role="doc-backlink">Alternate Interpolation Symbols</a></h3> In the early stages of this PEP, we considered allowing alternate symbols for interpolations in template strings. For example, we considered allowing <code class="docutils literal notranslate">${name}</code> as an alternative to <code class="docutils literal notranslate">{name}</code> with the idea that it might be useful for i18n or other purposes. See the <a class="reference external" href="https://discuss.python.org/t/pep-750-tag-strings-for-writing-domain-specific-languages/60408/122">Discourse thread</a> for more information. This was rejected in favor of keeping t-string syntax as close to f-string syntax as possible. </section> <section id="alternate-layouts-for-template"> <h3><a class="toc-backref" href="#alternate-layouts-for-template" role="doc-backlink">Alternate Layouts for <code class="docutils literal notranslate">Template</code></a></h3> During the development of this PEP, we considered several alternate layouts for the <code class="docutils literal notranslate">Template</code> type. Many focused on a single <code class="docutils literal notranslate">args</code> tuple that contained both strings and interpolations. Variants included: <ul class="simple"> <li><code class="docutils literal notranslate">args</code> was a <code class="docutils literal notranslate">tuple[str | Interpolation, ...]`</code> with the promise that its first and last items were strings and that strings and interpolations always alternated. This implied that <code class="docutils literal notranslate">args</code> was always non-empty and that empty strings would be inserted between neighboring interpolations. This was rejected because alternation could not be captured by the type system and was not a guarantee we wished to make.</li> <li><code class="docutils literal notranslate">args</code> remained a <code class="docutils literal notranslate">tuple[str | Interpolation, ...]</code> but did not support interleaving. As a result, empty strings were not added to the sequence. It was no longer possible to obtain static strings with <code class="docutils literal notranslate">args[::2]</code>; instead, instance checks or structural pattern matching had to be used to distinguish between strings and interpolations. This approach was rejected as offering less future opportunity for performance optimization.</li> <li><code class="docutils literal notranslate">args</code> was typed as a <code class="docutils literal notranslate">Sequence[tuple[str, Interpolation | None]]</code>. Each static string was paired with is neighboring interpolation. The final string part had no corresponding interpolation. This was rejected as being overly complex.</li> </ul> </section> <section id="mechanism-to-describe-the-kind-of-template"> <h3><a class="toc-backref" href="#mechanism-to-describe-the-kind-of-template" role="doc-backlink">Mechanism to Describe the “Kind” of Template</a></h3> If t-strings prove popular, it may be useful to have a way to describe the “kind” of content found in a template string: “sql”, “html”, “css”, etc. This could enable powerful new features in tools such as linters, formatters, type checkers, and IDEs. (Imagine, for example, <code class="docutils literal notranslate">black</code> formatting HTML in t-strings, or <code class="docutils literal notranslate">mypy</code> checking whether a given attribute is valid for an HTML tag.) While exciting, this PEP does not propose any specific mechanism. It is our hope that, over time, the community will develop conventions for this purpose. </section> <section id="binary-template-strings"> <h3><a class="toc-backref" href="#binary-template-strings" role="doc-backlink">Binary Template Strings</a></h3> The combination of t-strings and bytes (<code class="docutils literal notranslate">tb</code>) is considered out of scope for this PEP. However, unlike f-strings, there is no fundamental reason why t-strings and bytes cannot be combined. Support could be considered in a future PEP. </section> </section> <section id="acknowledgements"> <h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2> Thanks to Ryan Morshead for contributions during development of the ideas leading to template strings. Special mention also to Dropbox’s <a class="reference external" href="https://github.com/dropbox/pyxl">pyxl</a> for tackling similar ideas years ago. Andrea Giammarchi provided thoughtful feedback on the early drafts of this PEP. Finally, thanks to Joachim Viide for his pioneering work on the <a class="reference external" href="https://github.com/jviide/tagged">tagged library</a>. Tagged was not just the precursor to template strings, but the place where the whole effort started via a GitHub issue comment! </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. </section> </section> <hr class="docutils" /> Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0750.rst">https://github.com/python/peps/blob/main/peps/pep-0750.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0750.rst">2025-02-01 07:28:42 GMT</a> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#relationship-with-other-peps">Relationship With Other PEPs</a></li> <li><a class="reference internal" href="#motivation">Motivation</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#template-string-literals">Template String Literals</a></li> <li><a class="reference internal" href="#the-template-type">The <code class="docutils literal notranslate">Template</code> Type</a></li> <li><a class="reference internal" href="#the-interpolation-type">The <code class="docutils literal notranslate">Interpolation</code> Type</a></li> <li><a class="reference internal" href="#convenience-accessors-in-template">Convenience Accessors in <code class="docutils literal notranslate">Template</code></a></li> <li><a class="reference internal" href="#processing-template-strings">Processing Template Strings</a></li> <li><a class="reference internal" href="#template-string-concatenation">Template String Concatenation</a></li> <li><a class="reference internal" href="#template-and-interpolation-equality">Template and Interpolation Equality</a></li> <li><a class="reference internal" href="#no-support-for-ordering">No Support for Ordering</a></li> <li><a class="reference internal" href="#support-for-the-debug-specifier">Support for the debug specifier (<code class="docutils literal notranslate">=</code>)</a></li> <li><a class="reference internal" href="#raw-template-strings">Raw Template Strings</a></li> <li><a class="reference internal" href="#interpolation-expression-evaluation">Interpolation Expression Evaluation</a></li> <li><a class="reference internal" href="#exceptions">Exceptions</a></li> <li><a class="reference internal" href="#no-template-str-implementation">No <code class="docutils literal notranslate">Template.__str__()</code> Implementation</a></li> </ul> </li> <li><a class="reference internal" href="#examples">Examples</a><ul> <li><a class="reference internal" href="#example-implementing-f-strings-with-t-strings">Example: Implementing f-strings with t-strings</a></li> <li><a class="reference internal" href="#example-structured-logging">Example: Structured Logging</a><ul> <li><a class="reference internal" href="#approach-1-custom-log-messages">Approach 1: Custom Log Messages</a></li> <li><a class="reference internal" href="#approach-2-custom-formatters">Approach 2: Custom Formatters</a></li> </ul> </li> <li><a class="reference internal" href="#example-html-templating">Example: HTML Templating</a></li> </ul> </li> <li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a></li> <li><a class="reference internal" href="#security-implications">Security Implications</a></li> <li><a class="reference internal" href="#how-to-teach-this">How To Teach This</a></li> <li><a class="reference internal" href="#why-another-templating-approach">Why another templating approach?</a></li> <li><a class="reference internal" href="#common-patterns-seen-in-processing-templates">Common Patterns Seen in Processing Templates</a><ul> <li><a class="reference internal" href="#structural-pattern-matching">Structural Pattern Matching</a></li> <li><a class="reference internal" href="#memoizing">Memoizing</a></li> <li><a class="reference internal" href="#parsing-to-intermediate-representations">Parsing to Intermediate Representations</a></li> <li><a class="reference internal" href="#context-sensitive-processing-of-interpolations">Context-sensitive Processing of Interpolations</a></li> <li><a class="reference internal" href="#nested-template-strings">Nested Template Strings</a></li> <li><a class="reference internal" href="#approaches-to-lazy-evaluation">Approaches to Lazy Evaluation</a></li> <li><a class="reference internal" href="#approaches-to-asynchronous-evaluation">Approaches to Asynchronous Evaluation</a></li> <li><a class="reference internal" href="#approaches-to-template-reuse">Approaches to Template Reuse</a></li> <li><a class="reference internal" href="#relation-to-format-strings">Relation to Format Strings</a></li> </ul> </li> <li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#arbitrary-string-literal-prefixes">Arbitrary String Literal Prefixes</a></li> <li><a class="reference internal" href="#delayed-evaluation-of-interpolations">Delayed Evaluation of Interpolations</a></li> <li><a class="reference internal" href="#making-template-and-interpolation-into-protocols">Making <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code> Into Protocols</a></li> <li><a class="reference internal" href="#overridden-eq-and-hash-for-template-and-interpolation">Overridden <code class="docutils literal notranslate">__eq__</code> and <code class="docutils literal notranslate">__hash__</code> for <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code></a></li> <li><a class="reference internal" href="#an-additional-decoded-type">An Additional <code class="docutils literal notranslate">Decoded</code> Type</a></li> <li><a class="reference internal" href="#the-final-home-for-template-and-interpolation">The Final Home for <code class="docutils literal notranslate">Template</code> and <code class="docutils literal notranslate">Interpolation</code></a></li> <li><a class="reference internal" href="#enable-full-reconstruction-of-original-template-literal">Enable Full Reconstruction of Original Template Literal</a></li> <li><a class="reference internal" href="#disallowing-string-concatenation">Disallowing String Concatenation</a></li> <li><a class="reference internal" href="#arbitrary-conversion-values">Arbitrary Conversion Values</a></li> <li><a class="reference internal" href="#removing-conv-from-interpolation">Removing <code class="docutils literal notranslate">conv</code> From <code class="docutils literal notranslate">Interpolation</code></a></li> <li><a class="reference internal" href="#alternate-interpolation-symbols">Alternate Interpolation Symbols</a></li> <li><a class="reference internal" href="#alternate-layouts-for-template">Alternate Layouts for <code class="docutils literal notranslate">Template</code></a></li> <li><a class="reference internal" href="#mechanism-to-describe-the-kind-of-template">Mechanism to Describe the “Kind” of Template</a></li> <li><a class="reference internal" href="#binary-template-strings">Binary Template Strings</a></li> </ul> </li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0750.rst">Page Source (GitHub)</a> </nav> </section> <script src="../_static/colour_scheme.js"></script> <script src="../_static/wrap_tables.js"></script> <script src="../_static/sticky_banner.js"></script> </body> </html>