在將于 10 月初發布的 Python 3.12 中，我們將看到 f-strings 語法帶來了一些變化，新版取消了最初制定 f-strings 時制定的一些限制。經過這些變化，使得 f-strings 更加統一，成為一種可以直接整合到解析器中的正式化語法。這將會為終端用戶和庫開發者帶來較大優勢，同時也大大降低用于解析 f-strings 代碼的維護成本。

最初設置 f-strings 限制是為了能夠在不修改現有詞法分析器的情況下將 f-strings 的解析實現到 CPython 中。但目前來看，這些限制反而帶來了復雜性。比如：

1. 在表達式部分中，無法使用引號字符來界定 f-strings

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

1. 之前考慮過的一種解決方法會導致在執行的代碼中出現轉義序列，這在 f-strings 中是被禁止的：

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

1. f-strings 中無法使用注釋語法：

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

1. 許多其它語言表達式字符串插值都支持不擴展轉義序列的任意嵌套。比如：

# Ruby
"#{ "#{1+2}" }"

# JavaScript
`${`${1+2}`}`

# Swift
"\("\(1+2)")"

# C#
$"{$"{1+2}"}"

Python 團隊意識到，從語言用戶的角度來看，這些限制沒有任何意義，所以他們目前通過賦予 f-strings 字面量一個沒有例外的常規語法，并使用專用的解析代碼來實現它，從而消除這些限制。

f-strings 的另一個問題是，CPython 中的當前實現依賴于將 f-strings 標記化為 STRING 令牌，并對這些令牌進行后處理。這帶來了以下問題：

1. 它給 CPython 解析器增加了相當大的維護成本。這是因為解析代碼需要手動編寫，這在歷史上導致了大量的不一致性和錯誤。在 C 中手動編寫和維護解析代碼一直被認為是容易出錯和危險的，因為它需要處理大量的原始詞法分析器緩沖區上的手動內存管理。
2. f-strings 解析代碼無法使用新的 PEG 解析器所允許的新錯誤消息機制，這些錯誤消息帶來的改進已經受到了熱烈歡迎，但因為 f-strings 用的是獨立解析器，所以無法使用上新改進的錯誤消息機制。另外，因為 f-strings 有幾個語法特性可能會因為在表達式部分內部發生的不同隱式標記化而令人困惑（例如 f"{y:=3}" 并不是一個賦值表達式）。
3. 其它 Python 實現無法知道它們是否正確實現了 f-strings，因為它們并不是官方 Python 語法的一部分。這一點很重要，因為有幾個知名的替代實現正在使用 CPython 的 PEG 解析器，如 PyPy。f-strings 使用一個獨立的解析器，阻止了這些替代實現利用官方語法，以及從改進的錯誤消息機制中受益。

期待新 f-strings 能用得更順心。

具體情況可以查看 PEP-701：https://peps.python.org/pep-0701