PEP 750 introduced template strings (t-strings) as a generalization of f-strings, providing a way to safely handle string interpolation in various contexts. This PEP proposes extending the subprocess and shlex modules to natively support t-strings, enabling safer and more ergonomic shell command execution with interpolated values, as well as serving as a reference implementation for the t-string feature to improve API ergonomics.
During the discussions of the initial draft of the PEP, it became clear that t-strings provide a potential opportunity to offer shell=True levels of syntactic convenience for complex subprocess invocations without all of the security and cross-platform compatibility concerns that arise with giving user provided text access to a full system shell.
To that end, the PEP authors now plan to work on an experimental t-string based subprocess invocation library through the Python 3.14 beta period (and beyond), before preparing a revised draft of the proposal for Python 3.15.
Despite the safety benefits and flexibility that template strings offer in PEP 750, they lack a concrete consumer implementation in the standard library that demonstrates their practical application. One of the most compelling use cases for t-strings is safer shell command execution, as noted in the withdrawn PEP 501:
Currently, developers must choose between convenience (using f-strings with potential security risks) and safety (using more verbose, list-based APIs). By adding native t-string support to the subprocess module, we provide a consumer reference implementation that demonstrates the value of t-strings while addressing a common security concern.
The subprocess module is an ideal candidate for t-string support for several reasons:
By extending subprocess to handle t-strings natively, we make it easier to write secure code without sacrificing the convenience that led many developers to use potentially unsafe f-strings.
This PEP proposes two main additions to the standard library:
As a reference implementation, a renderer for safe POSIX shell escaping will be added to the shlex module. This renderer would be called sh and would be equivalent to calling shlex.quote on each field value in the template literal.
Thus:
would have the same behavior as:
The addition of shlex.sh will NOT change the existing admonishments in the subprocess documentation that passing shell=True is best avoided, nor the reference from the os.system() documentation to the higher level subprocess APIs.
The t-string processor implementation would look like:
This allows for explicit escaping of t-strings for shell usage:
With the additional renderer in the shlex module, and the addition of template strings, the subprocess module can be changed to handle accepting template strings as an additional input type to Popen, as it already accepts a sequence, or a string, with different behavior for each. In return, all subprocess.Popen higher level functions such as subprocess.run() could accept strings in a safe way (on all systems for shell=False and on POSIX systems for shell=True).
For example:
would automatically use the shlex.sh renderer provided in this PEP. Therefore, using shlex inside a subprocess.run call like so:
would be redundant, as run would automatically render any template literals through shlex.sh
When subprocess.Popen is called without shell=True, t-string support would still provide subprocess with a more ergonomic syntax. For example:
would be equivalent to:
or, more accurately:
It would do this by first using the shlex.sh renderer, as above, then using shlex.split on the result.
The implementation inside subprocess.Popen._execute_child would check for t-strings:
This change is fully backwards compatible as it only adds new functionality without altering existing behavior. The subprocess module will continue to handle strings and lists in the same way it currently does.
This PEP is explicitly designed to improve security by providing a safer alternative to using f-strings with shell commands. By automatically applying appropriate escaping based on context (shell or non-shell), it helps prevent command injection vulnerabilities.
However, it’s worth noting that when shell=True is used, the safety is limited to POSIX-compliant shells. On Windows systems where cmd.exe or PowerShell may be used as the shell, the escaping mechanism provided by shlex.quote() is not sufficient to prevent all forms of command injection.
This feature can be taught as a natural extension of t-strings that demonstrates their practical value:
The implementation should be added to both the shlex and subprocess module documentation with clear examples and security advisories.
shlex.quote() works by classifying the regex character set [\w@%+=:,./-] to be safe, deeming all other characters to be unsafe, and hence requiring quoting of the string containing them. The quoting mechanism used is then specific to the way that string quoting works in POSIX shells, so it cannot be trusted when running a shell that doesn’t follow POSIX shell string quoting rules.
For example, running subprocess.run(f"echo {shlex.quote(sys.argv[1])}", shell=True) is safe when using a shell that follows POSIX quoting rules:
but remains unsafe when running a shell from Python invokes cmd.exe (or Powershell):
Resolving this standard library limitation is beyond the scope of this PEP.
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.
Source: https://github.com/python/peps/blob/main/peps/pep-0787.rst
Last modified: 2025-04-27 15:17:24 UTC