摘要

本文件提議解除 PEP 498 最初制定的部分限制，並為 f-string 提供可直接整合至解析器（parser）中的形式化語法。提議的 f-string 語法形式化對 f-string 的解析與解釋方式會有些微副作用，但能為終端使用者與函式庫開發者帶來相當多的優勢，同時也大幅降低解析 f-string 程式碼的維護成本。

動機

當 f-string 最初在 PEP 498 中引入時，規範中並未提供 f-string 的正式語法。此外，規範中包含若干限制，這些限制是為了讓 f-string 的解析能在不修改現有詞法分析器（lexer）的情況下實作於 CPython。這些限制之前已被人們注意到，且過去曾試圖在 PEP 536 中解除它們，但這些工作從未被實作。其中一些限制（最初由 PEP 536 收集）為：

1. 無法在表達式部分內使用界定 f-string 的引號字元。

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

2. 先前考慮過的一種解決方法會導致執行中的程式碼出現跳脫序列（escape sequences），這在 f-string 中是被禁止的。

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

3. 即使在多行 f-string 中，註解也是被禁止的。

   >>> 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-string 字面值一個沒有例外情況的常規語法，並使用專門的解析程式碼來實作，從而解除這些限制。

f-string 面臨的另一個問題是，目前 CPython 的實作依賴於將 f-string 標記為 STRING Token 並對這些 Token 進行後處理。這存在以下問題：

1. 它增加了 CPython 解析器的維護成本。這是因為解析程式碼需要手寫，歷史上導致了相當多的不一致和錯誤。在 C 語言中手寫和維護解析程式碼一直被認為容易出錯且危險，因為它需要處理相對於原始詞法分析器緩衝區的大量手動記憶體管理。
2. f-string 解析程式碼無法利用由 PEP 617 最初引入的新 PEG 解析器所提供的新改進錯誤訊息機制。這些錯誤訊息帶來的改進廣受讚譽，但遺憾的是 f-string 無法從中受益，因為它們是在解析機制的獨立部分中解析的。這特別令人遺憾，因為 f-string 有幾個語法特徵可能會因為表達式內部發生的不同隱式詞法標記化而令人困惑（例如 f"{y:=3}" 並非賦值表達式）。
3. 其他 Python 實作無法得知它們是否正確實作了 f-string，因為與其他語言特性不同，它們不是官方 Python 語法的一部分。這一點很重要，因為一些著名的替代實作正在使用 CPython 的 PEG 解析器，例如 PyPy，和/或將其語法基於官方 PEG 語法。f-string 使用獨立解析器的事實，阻礙了這些替代實作利用官方語法，並從源自該語法的錯誤訊息改進中受益。

此提案的一個版本最初在 Python-Dev 上進行了討論，並在 2022 年 Python 語言峰會上發表，受到了熱烈的歡迎。

原理

透過建立在新的 Python PEG 解析器（PEP 617）之上，本 PEP 提議重新定義「f-string」，特別強調字串組件與表達式（或替換，{...}）組件的明確分離。PEP 498 將「f-string」的語法部分總結如下：

在 Python 原始程式碼中，f-string 是一種字面值字串，前綴為「f」，其中包含大括號內的表達式。這些表達式會被替換為它們的值。

然而，PEP 498 也包含了一份關於表達式組件內可以或不可以包含什麼的正式排除清單（主要是由於現有解析器的限制）。透過明確建立形式語法，我們現在也有能力將 f-string 的表達式組件定義為真正「任何適用的 Python 表達式」（在該特定上下文中），而不受實作細節所強加的限制束縛。

上述形式化努力和前提對於 Python 程式設計師來說也具有顯著的好處，因為它能夠簡化並消除模糊的限制。這減少了 f-string 字面值（以及一般 Python 語言）的精神負擔和認知複雜性。

1. 表達式組件可以包含任何普通 Python 表達式可以包含的字串字面值。這為在 f-string 的表達式組件中嵌套相同引號類型（和長度）的字串字面值（無論是否格式化）開啟了可能性。

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

   這種「功能」並未獲得普遍認可為理想的，一些使用者認為這難以閱讀。關於對此的不同觀點討論，請參閱關於引號重用的考量一節。

2. 另一個讓大多數人感到不直觀的問題是，f-string 的表達式組件內不支援反斜線。一個不斷出現的例子是在用於連接容器的表達式部分中包含換行字元。例如：

   >>> 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-string 之前先建立整個字串。

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

   現在新的 PEG 解析器可以輕鬆支援反斜線，在表達式部分允許反斜線感覺很自然。

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

3. 在本文件提議的變更之前，f-string 的嵌套方式沒有明確限制，但事實上，字串引號不能在 f-string 的表達式組件內重複使用，這使得無法任意嵌套 f-string。事實上，這是可以寫出的最深嵌套 f-string：

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

   由於本 PEP 允許在 f-string 的表達式組件中放置任何有效的 Python 表達式，因此現在可以重複使用引號，從而可以任意嵌套 f-string。

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

   儘管這只是允許任意表達式的結果，但本 PEP 的作者不認為這是一個根本性的好處，我們已決定語言規範不會明確強制要求這種嵌套可以是任意的。這是因為允許任意深度的嵌套會給詞法分析器的實作增加大量額外的複雜性（特別是因為詞法分析器/解析器管道需要允許「取消標記化（untokenizing）」以支援「f-string 除錯表達式」，而在允許任意嵌套時這尤其費力）。因此，實作如果需要，可以自由地對嵌套深度施加限制。請注意，這並非不常見的情況，因為 CPython 實作已經在各處施加了多個限制，包括對括號和中括號嵌套深度的限制、對區塊嵌套的限制、對 if 陳述式中分支數量的限制、對星號解包中表達式數量的限制等等。

規範

f-string 的形式化 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

新的 Token（FSTRING_START, FSTRING_MIDDLE, FSTRING_END）定義於本文件稍後部分。

本 PEP 將允許的 f-string 嵌套層級（f-string 內部的 f-string 表達式部分）交由實作決定，但指定了至少 5 層的嵌套下限。這是為了確保使用者對能夠以「合理」深度嵌套 f-string 有合理的期望。本 PEP 暗示限制嵌套並非語言規範的一部分，但同時語言規範也不強制要求任意嵌套。

同樣地，本 PEP 將格式說明符中的表達式嵌套層級交由實作決定，但指定了至少 2 層的嵌套下限。這意味著以下內容應始終有效：

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

但以下內容根據實作可能有效也可能無效：

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

新語法將保留當前實作的抽象語法樹 (AST)。這意味著本 PEP 不會對使用 f-string 的現有程式碼引入任何語義上的變更。

>>> 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 不會引入任何向後不相容的語法或語義變更。然而，tokenize 模組（標準函式庫的準公共部分）將需要更新以支援新的 f-string Token（以允許工具作者正確地對 f-string 進行標記化）。關於 tokenize 的公共 API 將如何受到影響的更多詳細資訊，請參閱tokenize 模組的變更。

如何教學

由於 f-string 的概念在 Python 社群中已無處不在，使用者沒有學習任何新事物的根本需要。然而，由於形式化語法允許一些新的可能性，因此將形式語法加入文件並詳細說明是很重要的，明確提到哪些構造是可能的，因為本 PEP 的目標是避免混淆。

為使用者提供一個簡單的框架來理解什麼可以放在 f-string 表達式中也是有益的。在這種情況下，作者認為這項工作將使解釋該語言的這一方面變得更加簡單，因為它可以總結為：

你可以在 f-string 表達式中放置任何有效的 Python 表達式。

透過本 PEP 中的變更，無需再澄清字串引號必須與封閉字串的引號不同，因為這現在是被允許的：正如任何任意的 Python 字串可以包含任何可能的引號選擇，任何 f-string 表達式也可以。此外，無需再因實作限制（如註解、換行字元或反斜線）而澄清表達式部分中某些東西是不允許的。

唯一「令人驚訝」的差異是，由於 f-string 允許指定格式，因此在頂層允許 : 字元的表達式仍需用括號括起來。這並非這項工作的新內容，但強調這一限制仍然存在是很重要的。這允許更簡單地修改總結：

你可以在 f-string 表達式中放置任何有效的 Python 表達式，並且在頂層 : 字元之後的所有內容都將被識別為格式說明。

參考實作

參考實作可以在 實作 分支中找到。

否決的想法

1. 雖然我們認為反對在 f-string 表達式中允許引號重用的可讀性論點是有效的且非常重要的，但我們已決定提議不在解析器層級拒絕 f-string 中的引號重用。原因是本 PEP 的基石之一是降低在 CPython 中解析 f-string 的複雜性和維護成本，這不僅會違背該目標，甚至可能使實作比當前更複雜。我們認為禁止引號重用應該在 linter 和程式碼風格工具中完成，而不是在解析器中，就像今天處理語言中其他令人困惑或難以閱讀的構造一樣。
2. 我們已決定不解除某些表達式部分需要在頂層將 ':' 和 '!' 用括號括起來的限制，例如：

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

   原因是這將引入大量的複雜性，卻沒有帶來真正的實質好處。這是由於 : 字元通常用來分隔 f-string 格式規範。此格式規範目前被標記化為字串。由於 tokenizer 必須將 : 右側的內容標記化為字串或 Token 流，這將不允許解析器區分不同的語義，因為那將需要 tokenizer 回溯並產生一組不同的 Token（即，首先嘗試作為 Token 流，如果失敗，則嘗試作為格式說明符的字串）。

   由於在頂層允許 lambda 和類似表達式沒有根本優勢，我們已決定保留這些必須在需要時用括號括起來的限制。

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

3. 我們已決定（暫時）不允許除了 {{ 和 }} 語法之外使用跳脫大括號（\{ 和 \}）。雖然 PEP 的作者認為允許跳脫大括號是一個好主意，但我們已決定不將其包含在本 PEP 中，因為它對於此處提議的 f-string 形式化並非絕對必要，並且可以在常規 CPython 問題中獨立添加。

待決問題

尚無

版權

本文件已進入公有領域或遵循 CC0-1.0-Universal 授權，以較寬鬆者為準。