摘要

本文档建议解除PEP 498中最初制定的某些限制，并为 f 字符串提供一个可以直接集成到解析器中的形式化语法。提议的 f 字符串语法形式化将对 f 字符串的解析和解释方式产生一些轻微的副作用，这将为最终用户和库开发人员带来大量优势，同时也会显著降低用于解析 f 字符串的代码的维护成本。

动机

当 f 字符串最初在PEP 498中引入时，规范是在没有为 f 字符串提供正式语法的基础上提供的。此外，该规范包含一些强制执行的限制，以便可以将 f 字符串的解析实现到 CPython 中，而无需修改现有的词法分析器。这些限制之前已被认识到，并且在PEP 536中曾尝试过解除它们，但是这些工作从未被实现。PEP 536最初收集了一些限制，具体如下：

1. 无法在表达式的部分使用分隔 f 字符串的引号字符

   >>> f'Magic wand: { bag['wand'] }'
                                ^
   SyntaxError: invalid syntax
   

2. 一种以前考虑过的方法会导致执行的代码中出现转义序列，并且在 f 字符串中是被禁止的

   >>> f'Magic wand { bag[\'wand\'] } string'
   SyntaxError: f-string expression portion cannot include a backslash
   

3. 即使在多行 f 字符串中，注释也是禁止的

   >>> f'''A complex trick: {
   ... bag['bag']  # recursive bags!
   ... }'''
   SyntaxError: f-string expression part cannot include '#'
   

4. 在许多其他使用表达式而不是仅使用变量名称的字符串插值方法的语言中，可以对表达式进行任意嵌套而无需展开转义序列。以下是一些例子

   # Ruby
   "#{ "#{1+2}" }"
   
   # JavaScript
   `${`${1+2}`}`
   
   # Swift
   "\("\(1+2)")"
   
   # C#
   $"{$"{1+2}"}"
   

这些限制从语言用户角度来看没有任何目的，并且可以通过为 f 字符串字面量提供没有异常的常规语法并使用专用解析代码来解除它们。

f 字符串的另一个问题是，CPython 中的当前实现依赖于将 f 字符串标记化为STRING标记，并对这些标记进行后处理。这存在以下问题：

1. 它为 CPython 解析器增加了相当大的维护成本。这是因为解析代码需要手动编写，这在历史上导致了许多不一致和错误。在 C 中手动编写和维护解析代码一直被认为是容易出错且危险的，因为它需要处理原始词法分析器缓冲区上的大量手动内存管理。
2. f 字符串解析代码无法使用 PEP 617 中最初引入的新 PEG 解析器允许的新的改进的错误消息机制。这些错误消息带来的改进得到了广泛的认可，但不幸的是，f 字符串无法从中受益，因为它们是在解析机制的另一个部分中解析的。这尤其令人遗憾，因为 f 字符串的几个语法特性由于表达式部分中发生的不同的隐式标记化而可能令人困惑（例如，f"{y:=3}" 不是赋值表达式）。
3. 其他 Python 实现无法知道它们是否正确地实现了 f 字符串，因为与其他语言特性不同，它们不是官方 Python 语法的一部分。这一点很重要，因为几个著名的替代实现正在使用 CPython 的 PEG 解析器，例如 PyPy，或者基于官方 PEG 语法。f 字符串使用单独的解析器，这阻止了这些替代实现利用官方语法并从语法中获得的错误消息改进中受益。

该提案的早期版本最初在Python-Dev 上进行了讨论，并在2022 年 Python 语言峰会上进行了介绍，并获得了热烈的欢迎。

基本原理

本 PEP 建议在新的 Python PEG 解析器 (PEP 617) 的基础上重新定义“f 字符串”，尤其强调字符串组件和表达式（或替换，{...}）组件之间的明确分离。PEP 498 将“f 字符串”的语法部分总结如下：

在 Python 源代码中，f 字符串是一个以“f”为前缀的字面字符串，其中包含大括号内的表达式。表达式将被其值替换。

但是，PEP 498 还包含一个正式的排除列表，列出了表达式组件中可以或不能包含的内容（主要是由于现有解析器的限制）。通过明确建立正式语法，我们现在也有能力将 f 字符串的表达式组件定义为真正的“任何适用的 Python 表达式”（在特定上下文中），而不受实现细节强加的限制的约束。

上述形式化工作和前提也为 Python 程序员带来了显著的益处，因为它能够简化和消除模糊的限制。这减少了 f 字符串字面量（以及整个 Python 语言）的心理负担和认知复杂度。

1. 表达式组件可以包含任何普通 Python 表达式可以包含的字符串字面量。这打开了在 f 字符串的表达式组件中嵌套字符串字面量（格式化与否）的可能性，并且这些字符串字面量使用相同的引号类型（和长度）。

   >>> f"These are the things: {", ".join(things)}"
   
   >>> f"{source.removesuffix(".py")}.c: $(srcdir)/{source}"
   
   >>> f"{f"{f"infinite"}"}" + " " + f"{f"nesting!!!"}"
   

   此“功能”并非普遍被认为是可取的，一些用户发现它难以阅读。有关对此的不同观点的讨论，请参阅关于引号重用的注意事项部分。

2. 另一个大多数人认为不直观的问题是，f 字符串的表达式组件中不支持反斜杠。一个经常出现的例子是在表达式的部分中包含换行符以连接容器。例如：

   >>> a = ["hello", "world"]
   >>> f"{'\n'.join(a)}"
   File "<stdin>", line 1
       f"{'\n'.join(a)}"
                       ^
   SyntaxError: f-string expression part cannot include a backslash
   

   对此的常见解决方法是将换行符赋值给中间变量，或在创建 f 字符串之前预先创建整个字符串。

   >>> a = ["hello", "world"]
   >>> joined = '\n'.join(a)
   >>> f"{joined}"
   'hello\nworld'
   

   现在新的 PEG 解析器可以轻松地支持反斜杠，因此在表达式的部分中允许反斜杠显得更加自然。

   >>> a = ["hello", "world"]
   >>> f"{'\n'.join(a)}"
   'hello\nworld'
   

3. 在本文档中提出的更改之前，f 字符串的嵌套方式没有明确的限制，但由于字符串引号无法在 f 字符串的表达式组件中重复使用，因此无法对 f 字符串进行任意嵌套。实际上，这可以写入的最嵌套的 f 字符串：

   >>> f"""{f'''{f'{f"{1+1}"}'}'''}"""
   '2'
   

   由于本 PEP 允许将任何有效的 Python 表达式放置在 f 字符串的表达式组件中，因此现在可以重复使用引号，因此可以对 f 字符串进行任意嵌套。

   >>> f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}"
   '2'
   

   虽然这只是允许任意表达式的一个结果，但本 PEP 的作者并不认为这是一个根本性的优势，我们已决定语言规范不会明确要求这种嵌套可以是任意的。这是因为允许任意深度的嵌套会给词法分析器实现带来很多额外的复杂性（尤其是在词法分析器/解析器管道需要允许“取消标记化”以支持“f 字符串调试表达式”的情况下，并且在允许任意嵌套时，这会特别繁重）。因此，实现可以自由地根据需要对嵌套深度施加限制。请注意，这种情况并不罕见，因为 CPython 实现已经在很多地方施加了几个限制，包括对括号和方括号嵌套深度的限制、对块嵌套的限制、if 语句中分支数量的限制、星号解包中表达式数量的限制等。

规范

f 字符串的正式建议的 PEG 语法规范如下（有关语法的详细信息，请参阅PEP 617）：

fstring
    | FSTRING_START fstring_middle* FSTRING_END
fstring_middle
    | fstring_replacement_field
    | FSTRING_MIDDLE
fstring_replacement_field
    | '{' (yield_expr | star_expressions) "="? [ "!" NAME ] [ ':' fstring_format_spec* ] '}'
fstring_format_spec:
    | FSTRING_MIDDLE
    | fstring_replacement_field

新标记 (FSTRING_START, FSTRING_MIDDLE, FSTRING_END) 在本文档的后面部分定义。

本 PEP 将允许的 f 字符串嵌套级别（其他 f 字符串的表达式部分中的 f 字符串）留给实现，但指定了 5 级嵌套的下限。这样做是为了确保用户可以合理地预期能够以“合理”的深度嵌套 f 字符串。本 PEP 意味着限制嵌套不是语言规范的一部分，但语言规范也没有强制执行任意嵌套。

类似地，本 PEP 将格式说明符中允许的表达式嵌套级别留给实现，但指定了 2 级嵌套的下限。这意味着以下内容应该始终有效：

f"{'':*^{1:{1}}}"

但以下内容可能有效或无效，具体取决于实现：

f"{'':*^{1:{1:{1}}}}"

新的语法将保留当前实现的抽象语法树 (AST)。这意味着本 PEP 不会对使用 f 字符串的现有代码引入任何语义更改。

>>> a = 1
>>> f"{1+1=}"
'1+1=2'

f'some words {a+b:.3f} more words {c+d=} final words'

FSTRING_START - "f'"
FSTRING_MIDDLE - 'some words '
LBRACE - '{'
NAME - 'a'
PLUS - '+'
NAME - 'b'
OP - ':'
FSTRING_MIDDLE - '.3f'
RBRACE - '}'
FSTRING_MIDDLE - ' more words '
LBRACE - '{'
NAME - 'c'
PLUS - '+'
NAME - 'd'
OP - '='
RBRACE - '}'
FSTRING_MIDDLE - ' final words'
FSTRING_END - "'"

FSTRING_START - 'f"""'
FSTRING_MIDDLE - 'some words'
FSTRING_END - '"""'

>>> f" something { my_dict["key"] } something else "

向后兼容性

本 PEP 不会对 Python 语言引入任何向后不兼容的语法或语义更改。但是，tokenize 模块（标准库的准公共部分）需要更新以支持新的 f 字符串令牌（以允许工具作者正确地对 f 字符串进行标记）。有关 tokenize 的公共 API 将如何受到影响的更多详细信息，请参阅 对 tokenize 模块的更改。

如何教授

由于 f 字符串的概念在 Python 社区中已经普遍存在，因此用户无需学习任何新内容。但是，由于正式的语法允许一些新的可能性，因此将正式语法添加到文档中并详细解释它很重要，明确提到哪些结构是可能的，因为本 PEP 的目标是避免混淆。

为用户提供一个简单的框架来理解可以在 f 字符串表达式中放置什么也很有益。在这种情况下，作者认为这项工作将使解释语言的这方面变得更加简单，因为它可以概括为

您可以在 f 字符串表达式中放置任何有效的 Python 表达式。

随着本 PEP 中的更改，无需澄清字符串引号仅限于与封闭字符串的引号不同，因为现在允许这样做：由于任意 Python 字符串可以包含任何可能的引号选择，因此任何 f 字符串表达式也可以。此外，无需澄清由于实现限制（如注释、换行符或反斜杠）在表达式部分中不允许某些内容。

唯一的“令人惊讶”的差异是，由于 f 字符串允许指定格式，因此在顶层允许 : 字符的表达式仍然需要用括号括起来。这对于这项工作来说并不新鲜，但重要的是要强调这种限制仍然存在。这使得更容易修改摘要

您可以在 f 字符串表达式中放置任何有效的 Python 表达式，并且顶层 : 字符后面的所有内容都将被识别为格式规范。

参考实现

可以在 实现 分支中找到参考实现。

被拒绝的想法

1. 虽然我们认为针对允许在 f 字符串表达式中重复使用引号提出的可读性论据是有效的且非常重要的，但我们已决定建议不要在解析器级别拒绝在 f 字符串中重复使用引号。原因是本 PEP 的基石之一是减少在 CPython 中解析 f 字符串的复杂性和维护，这不仅会违背这个目标，甚至可能使实现比当前实现更加复杂。我们相信禁止重复使用引号应该在代码 linter 和代码样式工具中完成，而不是在解析器中完成，就像今天处理语言中其他令人困惑或难以理解的结构一样。
2. 我们决定不取消某些表达式部分需要在顶层用括号括起来 ':' 和 '!' 的限制，例如

   >>> f'Useless use of lambdas: { lambda x: x*2 }'
   SyntaxError: unexpected EOF while parsing
   

   原因是这将引入相当多的复杂性，而没有真正的益处。这是因为 : 字符通常用于分隔 f 字符串格式规范。此格式规范当前被标记为字符串。由于标记器必须将 : 右侧的内容标记为字符串或令牌流，因此这将不允许解析器区分不同的语义，因为这将要求标记器回溯并生成不同的令牌集（即，首先尝试作为令牌流，如果失败，则尝试作为格式规范的字符串）。

   由于在顶层允许 lambda 和类似表达式没有根本优势，因此我们决定保留必须对这些表达式进行括号括起来的限制（如果需要）

   >>> f'Useless use of lambdas: { (lambda x: x*2) }'
   

3. 我们决定禁止（暂时）使用转义大括号 (\{ 和 \})，除了 {{ 和 }} 语法。虽然 PEP 的作者认为允许转义大括号是一个好主意，但我们决定不将其包含在本 PEP 中，因为它对于这里提出的 f 字符串形式化来说并不严格必要，它可以独立地在常规的 CPython 问题中添加。

未解决的问题

目前还没有

版权

本文档属于公有领域或根据 CC0-1.0-Universal 许可证发布，以最宽松的许可证为准。