在将于 10 月初发布的 Python 3.12 中，我们将看到 f-strings 语法带来了一些变化，新版取消了最初制定 f-strings 时制定的一些限制。经过这些变化，使得 f-strings 更加统一，成为一种可以直接整合到解析器中的正式化语法。这将会为终端用户和库开发者带来较大优势，同时也大大降低用于解析 f-strings 代码的维护成本。
![]()
最初设置 f-strings 限制是为了能够在不修改现有词法分析器的情况下将 f-strings 的解析实现到 CPython 中。但目前来看，这些限制反而带来了复杂性。比如：
- 在表达式部分中，无法使用引号字符来界定 f-strings
>>> f'Magic wand: { bag['wand'] }'
^
SyntaxError: invalid syntax
- 之前考虑过的一种解决方法会导致在执行的代码中出现转义序列，这在 f-strings 中是被禁止的：
>>> f'Magic wand { bag[\'wand\'] } string'
SyntaxError: f-string expression portion cannot include a backslash
- f-strings 中无法使用注释语法：
>>> f'''A complex trick: {
... bag['bag'] # recursive bags!
... }'''
SyntaxError: f-string expression part cannot include '#'
- 许多其它语言表达式字符串插值都支持不扩展转义序列的任意嵌套。比如：
# Ruby
"#{ "#{1+2}" }"
# JavaScript
`${`${1+2}`}`
# Swift
"\("\(1+2)")"
# C#
$"{$"{1+2}"}"
Python 团队意识到，从语言用户的角度来看，这些限制没有任何意义，所以他们目前通过赋予 f-strings 字面量一个没有例外的常规语法，并使用专用的解析代码来实现它，从而消除这些限制。
f-strings 的另一个问题是，CPython 中的当前实现依赖于将 f-strings 标记化为 STRING 令牌，并对这些令牌进行后处理。这带来了以下问题：
- 它给 CPython 解析器增加了相当大的维护成本。这是因为解析代码需要手动编写，这在历史上导致了大量的不一致性和错误。在 C 中手动编写和维护解析代码一直被认为是容易出错和危险的，因为它需要处理大量的原始词法分析器缓冲区上的手动内存管理。
- f-strings 解析代码无法使用新的 PEG 解析器所允许的新错误消息机制，这些错误消息带来的改进已经受到了热烈欢迎，但因为 f-strings 用的是独立解析器，所以无法使用上新改进的错误消息机制。另外，因为 f-strings 有几个语法特性可能会因为在表达式部分内部发生的不同隐式标记化而令人困惑（例如
f"{y:=3}" 并不是一个赋值表达式）。
- 其它 Python 实现无法知道它们是否正确实现了 f-strings，因为它们并不是官方 Python 语法的一部分。这一点很重要，因为有几个知名的替代实现正在使用 CPython 的 PEG 解析器，如 PyPy。f-strings 使用一个独立的解析器，阻止了这些替代实现利用官方语法，以及从改进的错误消息机制中受益。
期待新 f-strings 能用得更顺心。
具体情况可以查看 PEP-701：https://peps.python.org/pep-0701
