摘要

本文档提议取消 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 解析器带来了相当大的维护成本。这是因为解析代码需要手动编写，这在历史上导致了大量的F不一致和错误。手动编写和维护 C 语言解析代码一直被认为是容易出错和危险的，因为它需要处理大量关于原始词法分析器缓冲区的手动内存管理。
2. f-字符串解析代码无法使用新的改进的错误消息机制，这些机制是由 PEP 617 中引入的新 PEG 解析器所允许的。这些错误消息带来的改进受到了广泛的赞扬，但不幸的是，f-字符串无法从中受益，因为它们是在解析机制的独立部分中解析的。这尤其不幸，因为 f-字符串有几个语法特性可能会由于表达式部分内部发生的不同隐式分词而令人困惑（例如 f"{y:=3}" 不是赋值表达式）。
3. 其他 Python 实现无法知道它们是否正确实现了 f-字符串，因为与所有其他语言特性不同，它们不是 官方 Python 语法 的一部分。这很重要，因为一些著名的替代实现正在使用 CPython 的 PEG 解析器，例如 PyPy，并且/或者它们的语法基于官方 PEG 语法。f-字符串使用单独的解析器这一事实阻碍了这些替代实现利用官方语法并从语法派生的错误消息改进中受益。

本提案的一个版本最初在 Python-Dev 上进行了讨论，并于 Python 语言峰会 2022 上发表，获得了热烈反响。

基本原理

本 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 允许在 f-字符串的表达式部分放置**任何**有效的 Python 表达式，现在可以重复使用引号，因此可以任意嵌套 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 表达式，并且顶层 : 字符之后的所有内容都将被识别为格式规范。

参考实现

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

被拒绝的想法

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 许可证下，以更宽松者为准。