Why Python 3.14 Introduces T‑Strings: A Safer Alternative to f‑Strings

Python 3.14 is arriving, and although it brings few syntax changes, the Python Software Foundation unexpectedly decided to accept the template‑string (t‑string) syntax proposed by PEP 750 as a new feature.

Template string (t‑string) syntax (proposed by PEP 750) has been accepted as a new feature in Python 3.14.

When I first heard this, I was a bit confused.

Python already has many string‑formatting methods, such as:

Using the % operator for C‑style formatting.

The .format() function, popular before f‑strings were introduced in Python 3.6.

F‑strings, which many developers prefer for their convenience and elegance.

So why do we need another string‑formatting syntax?

T‑String’s Purpose

Simply put, it aims to solve potential security issues that can arise when f‑strings handle string expressions .

For example, constructing an SQL query with an f‑string is dangerous:

<code>sql = f"SELECT info FROM users WHERE name = '{user}'"
</code>

This classic SQL injection can easily bypass authentication and retrieve all user data:

<code>user_input = "'Yang' OR '1'='1'"
sql_query = f"SELECT info FROM users WHERE name = {user}"
print(sql_query)
# SELECT info FROM users WHERE name = 'Yang' OR '1'='1'
</code>

Current Python versions have no syntax‑level solution to prevent SQL injection, but we can follow good practices:

Always validate user input before processing.

Validate parameters before using them in functions.

Use parameterized queries to execute SQL.

For instance, with SQLite we can run a safe query:

<code>import sqlite3
conn = sqlite3.connect("mydb.sqlite")
cursor = conn.cursor()
cursor.execute("SELECT info FROM users WHERE name = ?", (user_input,))
rows = cursor.fetchall()
</code>

Because the database engine treats parameters as data, special characters are escaped .

Or a good ORM can handle escaping for us, as in Django:

<code># Using Django ORM
from django.contrib.auth.models import User
users = User.objects.filter(username=user_input)
</code>

But SQL injection is not the only security concern; improper string handling can also lead to XSS when inserting data into HTML:

<code>user = "<script>alert('evil')</script>"
dangerous_html = f"<h1>Welcome, {user}!</h1>"
</code>

Fundamentally, f‑strings (and % or format ) provide no opportunity to clean or transform values before they become part of the final string, leaving developers to perform manual checks.

Introducing a syntax‑level mechanism like t‑strings could greatly improve safety.

How to Use T‑String Correctly

The syntax is simple: replace the f prefix with t .

Unlike f‑strings, a t‑string literal evaluates to a new Template object (imported from string.templatelib ) that contains both static parts and dynamic expressions:

<code>from string.templatelib import Template
name = "Yang"
welcome_message = t"Hello {name}!"
assert isinstance(welcome_message, Template)
# True
</code>

The template is not a real string but a Template object, and Template.__str__ is not defined, so str(welcome_message) does not directly produce "Hello Yang!".

It must be processed by a function to render the final string, allowing safe transformation or escaping before output.

Here is a simple safe HTML renderer for a t‑string:

<code># A safe HTML renderer
def html(template: Template) -> str:
    result_parts = []
    for item in template:
        if isinstance(item, str):
            result_parts.append(item)  # static part stays unchanged
        else:
            text = str(item.value)
            safe_text = (text.replace("<", "&lt;")
                             .replace(">", "&gt;"))
            result_parts.append(safe_text)
    return "".join(result_parts)

user = "<script>alert('evil')</script>"
dangerous_html = t"<h1>Welcome, {user}!</h1>"
print(html(dangerous_html))
# Output: <h1>Welcome, &lt;script&gt;alert('evil')&lt;/script&gt;!</h1>
</code>

In production you would typically use f -strings together with html.escape() :

<code>import html
user = "<script>alert('evil')</script>"
safe_html = f"<h1>Welcome, {html.escape(user)}!</h1>"
print(safe_html)
# <h1>Welcome, &lt;script&gt;alert(&#x27;evil&#x27;)&lt;/script&gt;!</h1>
</code>

If f‑strings can already achieve the same result, is t‑string still necessary? In my view, t‑strings provide greater flexibility and possibilities for string handling.

Because a t‑string carries all data (static and interpolated) in a Template object, its final output depends entirely on the rendering function, allowing not just escaped strings but also custom behaviors such as logging warnings, handling multiple content types, or asynchronous rendering.

For more syntax details, refer to PEP 750.

Summary

Overall, the t‑string syntax introduced in Python 3.14 offers a new way to avoid common security issues like XSS and SQL injection inherent in older string‑formatting methods.

It is based on a Template object that captures the structure of a string template (literals + expressions). By writing custom rendering logic, we can safely transform the Template into a secure string or other representations.

With thoughtful design, t‑strings can become a powerful tool in Python developers' security arsenal, complementing existing best practices of input validation and escaping.