PEP 584：字典合併操作符來了

???? “Python貓” ，一個值得加星標的公衆號

花下貓語：最新發布的 Python 3.9 預覽版合入了一個很小的改動（PEP-584），關於這個特性本身不需要多說，只需要一兩個示例，大家就能接受使用。但是，就像我之前介紹過的一些 PEP 一樣，關於它的來龍去脈和引起的相關討論，都是挺有意思的細節。今天分享的文章，對此有詳盡的梳理，推薦大家一讀。

劇照 | 《我的天才女友》

來源：Prodesire@Prodesire公衆號

一、前言

就在本週，字典合併特性（PEP 584^[1]）的提交被合入了 CPython 的主幹分支，並在 2020-02-26 發佈了 Python 3.9.0a4^[2] 預覽版本。

那什麼是字典合併操作符呢？在回答這個問題前，我們不妨回憶下集合的合併操作。當我們想要對兩個結合做合併操作時，會怎麼做呢？

>>> s1 = {1, 2}
>>> s2 = {2, 3}
>>> s1 | s2  # s1 和 s2 取並集，生成新的集合；與 s1.union(s2) 等價
{1, 2, 3}
>>> s1 |= s2 # s1 和 s2 取並集，並更新到 s1 上；與 s1.update(s2) 等價
>>> s1
{1, 2, 3}

類似地，我們希望 Python 中的字典能像集合一樣，使用 | 和 |= 作爲合併操作符，以解決我們在過去合併字典時感受到的“痛苦”，於是就有了 PEP 584。

今天就想和大家聊聊這個提案，不僅是要了解字典合併操作符的前世今生，更是要學習提案作者以及參與者是如何對引入一個新特性的思考，辯證性地分析利弊，最終確定引入。最後還想和大家分享下在 CPython 層面是如何實現的。

二、背景

在平時使用 Python 的過程中，我們有時會需要合併字典。目前合併字典有多種方式，它們或多或少都有些缺點。

2.1 dict.update

d1.update(d2) 確實能合併兩個字典，但它是在修改d1的基礎上進行。如果我們想要合併成一個新的字典，沒有一個直接使用表達式的方式，而需要藉助臨時變量進行：

e = d1.copy()
e.update(d2)

2.2 {d1, d2}

字典解包可以將兩個字典合併爲一個新的字典，但看起來有些醜陋，並且不能讓人顯而易見地看出這是在合併字典。

{**d1, **d2} 還會忽略映射類型，並始終返回字典類型。

2.3 collections.ChainMap

ChainMap 很少有人知道，它也可以用作合併字典。但和前面合併方式相反，在合併兩個字典時，第一個字典的鍵會覆蓋第二個字典的相同鍵。

此外，由於 ChainMap 是對入參字典的封裝，這意味着寫入 ChainMap 會修改原始字典：

>>> from collections import ChainMap
>>> d1 = {'a':1}
>>> d2 = {'a':2}
>>> merged = ChainMap(d1, d2)
>>> merged['a']     # d1['a'] 會覆蓋 d2['a']
1
>>> merged['a'] = 3# 實際等同於 d1['a'] = 3
>>> d1
{'a': 3}

2.4 dict(d1, **d2)

這是一種鮮爲人知的合併字典的“巧妙方法”，但如果字典的鍵不是字符串，它就不能有效工作了：

>>> d1 = {'a': 1}
>>> d2 = {2: 2}
>>> dict(d1, **d2)
Traceback (most recent call last):
  ...
TypeError: keywords must be strings

三、原理

新操作符同 dict.update 方法的關係，就和列表連接（+）、擴展（+=）操作符同 list.extend 方法的關係一樣。需要注意的是，這和集合中 |/|= 操作符同 set.update 的關係稍有不同。作者明確了允許就地運算符接受更廣泛的類型（就像 list 那樣）是一種更有用的設計，並且限制二進制操作符的操作數類型（就像 list 那樣）將有助於避免由複雜的隱式類型轉換引起的錯誤被吞掉。

>>> l1 = [1, 2]
>>> l1 + (3,) # 限制操作數的類型，不是列表就報錯
Traceback (most recent call last)
...
TypeError: can only concatenate list (not"tuple") to list
>>> l1 += (3,) # 允許就地運算符接受更廣泛的類型（如元組）
>>> l1
[1, 2, 3]

當合並字典發生鍵衝突時，以最右邊的值爲準。這和現存的字典類似操作相符，比如：

{'a': 1, 'a': 2} # 2 覆蓋 1
{**d, **e}       # e覆蓋d中相同鍵所對應的值
d.update(e)      # e覆蓋d中相同鍵所對應的值
d[k] = v         # v 覆蓋原有值
{k: v for x in (d, e) for (k, v) in x.items()} # e覆蓋d中相同鍵所對應的值

四、規範

字典合併會返回一個新字典，該字典由左操作數與右操作數合併而成，每個操作數必須是 dict（或 dict 子類的實例）。如果兩個操作數中都出現一個鍵，則最後出現的值（即來自右側操作數的值）將會覆蓋：

>>> d = {'spam': 1, 'eggs': 2, 'cheese': 3}
>>> e = {'cheese': 'cheddar', 'aardvark': 'Ethel'}
>>> d | e
{'spam': 1, 'eggs': 2, 'cheese': 'cheddar', 'aardvark': 'Ethel'}
>>> e | d # 不符合交換律，左右互換操作數會得到不同的結果
{'aardvark': 'Ethel', 'spam': 1, 'eggs': 2, 'cheese': 3}

擴展賦值版本的就地操作：

>>> d |= e # 將 e 更新到 d 中
>>> d
{'spam': 1, 'eggs': 2, 'cheese': 'cheddar', 'aardvark': 'Ethel'}

擴展賦值的行爲和字典的 update 方法完全一樣，它還支持任何實現了映射協議（更確切地說是實現了 keys 和 __getitem__ 方法）或鍵值對迭代對象。所以：

>>> d | [('spam', 999)]   # “原理”章節中提到限制操作數的類型，不是字典或字典子類就報錯
Traceback (most recent call last):
  ...
TypeError: can only merge dict (not"list") to dict

>>> d |= [('spam', 999)]  # “原理”章節中提到允許就地運算符接受更廣泛的類型，其行爲和 update 一樣，接受鍵值對迭代對象
>>> d
{'eggs': 2, 'cheese': 'cheddar', 'aardvark': 'Ethel', 'spam': 999}

五、主流觀點

5.1 字典合併不符合交換律

合併是符合交換律的，但是字典聯合卻沒有（d | e != e | d）。

迴應

Python 中有過不符合交換律的合併先例：

>>> {0} | {False}
{0}
>>> {False} | {0}
{False}

上述結果雖然是相等的，但是本質是不同的。通常來說，a | b 和 b | a 並不相同。

5.2 字典合併並不高效

類似管道寫法使用多次字典合併並不高效，比如 d | e | f | g | h 會創建和銷燬三個臨時映射。

迴應

這種問題在序列級聯時同樣會出現。

序列級聯的每一次合併都會使序列中的元素總數增加，最終會帶來 O(N^2) 的性能開銷。而字典合併有可能會有重複鍵，因此臨時映射的大小並不會如此快速地增長。

正如我們很少將大量的列表或元組連接在一起一樣，PEP的作者任務合併大量的字典也是少見情況。若是確實有這樣的訴求，那麼最好使用顯式的循環和就地合併：

new = {}
for d in many_dicts:
    new |= d

5.3 字典合併是有損的

字典合併可能會丟失數據（相同鍵的值可能消失），其他形式的合併並不會。

迴應

作者並不覺得這種有損是一個問題。此外，dict.update 也會發生這種情況，但並不會丟棄鍵，這其實是符合預期的。只不過是現在使用的不是 update 而是 |。

如果從不可逆的角度考慮，其他類型的合併也是有損的。假設 a | b 的結果是365，那麼 a 和 b 是多少卻不得而知。

5.4 只有一種方法達到目的

字典合併不符合“Only One Way”的禪宗。

迴應

其實並沒有這樣的禪宗。“Only One Way”起源於很早之前Perl社區對Python的誹謗。

5.5 超過一種方法達到目的

好吧，禪宗並沒有說“Only One Way To Do It”。但是它明確禁止“超過一種方法達到目的”。

迴應

並沒有這樣的禁止。Python 之禪僅表達了對“僅一種顯而易見的方式”的偏愛。

There should be one-- and preferably only one --obvious way to do
it.

它的重點是應該有一種明顯的方式達到目的。對於字典更新操作來說，我們可能希望至少執行兩個不同的操作：

就地更新字典：顯而易見的方式是使用 update() 方法。如果此提案被接受，|= 擴展賦值操作符也將等效，但這是擴展賦值如何定義的副作用。選擇哪種取決於使用者口味。
合併兩個現存的字典到新字典中：此提案中顯而易見的方法是使用 | 合併操作符。

實際上，Python 裏經常違反對“僅一種方式”的偏愛。例如，每個 for 循環都可以重寫爲 while 循環；每個 if 塊都可以寫爲 if/else 塊。列表、集合和字典推導都可以用生成器表達式代替。列表提供了不少於五種方法來實現級聯：

級聯操作符：a + b
就地級聯操作符：a + = b
切片分配：a[len(a):] = b
序列解壓縮：[*a, *b]
擴展方法：a.extend(b)

我們不能太教條主義，不能因爲它違反了“僅一種方式”就非常嚴格的拒絕有用的功能。

5.6 字典合併讓代碼更難理解

字典合併讓人們更難理解代碼的含義。爲了解釋該異議，而不是具體引用任何人的話：“在看到 spam | eggs，如果不知道 spam 和 eggs 是什麼，根本就不知道這個表達式的作用”。

迴應

這確實如此，即使沒有該提案，| 操作符的現狀也是如此：

對於 int/bool 是按位或
對於 set/forzenset 是並集
還可能是任何其他的重載操作

添加字典合併看起來並不會讓理解代碼變得更困難。確定 spam 和 eggs 是映射類型並不比確定是集合還是整數要花更多的工作。其實良好的命名約定將會有助於改善情況：

flags |= WRITEABLE  # 可能就是數字的按位或
DO_NOT_RUN = WEEKENDS | HOLIDAYS  # 可能就是集合合併
settings = DEFAULT_SETTINGS | user_settings | workspace_settings  # 可能就是字典合併

5.7 參考下完整的集合API

字典和集合很相似，應該要支持集合所支持的操作符：|、&、^ 和 -。

迴應

也許後續會有PEP來專門說明這些操作符如何用於字典。簡單來說：

把集合的對稱差集（^）操作用在字典上面是顯而易見且自然。比如：

>>> d1 = {"spam": 1, "eggs": 2}
>>> d2 = {"ham": 3, "eggs": 4}

對於 d1 和 d2 對稱差集，我們期望 d1 ^ d2 應該是 {"spam": 1, "ham": 3}

把集合的差集（-）操作用在字典上面也是顯而易見和自然的。比如 d1 和 d2 的差集，我們期望：

d1 - d2 爲 {"spam": 1}
d2 - d1 爲 {"ham": 3}

把集合的交集（&）操作用在字典上面就有些問題了。雖然很容易確定兩個字典中鍵的交集，但是如何處理鍵所對應的值就比較模糊。不難看出 d1 和 d2 的共同鍵是 eggs，如果我們遵循“後者勝出”的一致性原則，那麼值就是 4。

六、已拒絕的觀點

PEP 584 提案中羅列了很多已拒絕的觀點，比如使用 + 來合併字典；在合併字典時也合併值類型爲列表的值等等。這些觀點都非常有意思，被拒絕的理由也同樣有說服力。限於篇幅的原因不再進一步展開，感興趣的可以閱讀 https://www.python.org/dev/peps/pep-0584/#id34。

七、實現

7.1 純 Python 實現

def __or__(self, other):
    ifnot isinstance(other, dict):
        returnNotImplemented
    new = dict(self)
    new.update(other)
    return new

def __ror__(self, other):
    ifnot isinstance(other, dict):
        returnNotImplemented
    new = dict(other)
    new.update(self)
    return new

def __ior__(self, other):
    dict.update(self, other)
    return self

純 Python 實現並不複雜，我們只需讓 dict 實現幾個魔法方法：

__or__ 和 __ror__ 魔法方法對應於 | 操作符，__or__ 表示對象在操作符左側，__ror__ 表示對象在操作符右側。實現就是根據左側操作數生成一個新字典，再把右側操作數更新到新字典中，並返回新字典。
__ior__ 魔法方法對應於 |= 操作符，將右側操作數更新到自身即可。

7.2 CPython 實現

CPython 中字典合併的詳細實現可見此 PR：https://github.com/python/cpython/pull/12088/files 。

最核心的實現如下：

// 實現字典合併生成新字典的邏輯，對應於 | 操作符
static PyObject *
dict_or(PyObject *self, PyObject *other)
{
    if (!PyDict_Check(self) || !PyDict_Check(other)) {
        Py_RETURN_NOTIMPLEMENTED;
    }
    PyObject *new = PyDict_Copy(self);
    if (new == NULL) {
        returnNULL;
    }
    if (dict_update_arg(new, other)) {
        Py_DECREF(new); // 減少引用計數
        returnNULL;
    }
    returnnew;
}

// 實現字典就地合併邏輯，對應於 |= 操作符
static PyObject *
dict_ior(PyObject *self, PyObject *other)
{
    if (dict_update_arg(self, other)) {
        returnNULL;
    }
    Py_INCREF(self); // 增加引用計數
    return self;
}

CPython 的實現邏輯和純Python實現幾乎一樣，唯獨需要注意的就是引用計數的問題，這關係到對象的垃圾回收。

八、總結

PEP 584 是一個非常精彩的提案，引入 | 和 |= 操作符用作字典合併，看似是一個比較簡單的功能，但所要考慮的情況卻不少。不僅需要說明這個提案的背景，目前有哪些方式可以達到目的，它們有哪些痛點；還要考慮對既有類型引入操作符所帶來的各種影響，對開發者提出的質疑和顧慮進行思考和解決。整個提案所涉及到的方法論、思考維度、知識點都非常值得學習。

對使用者來說，合併字典將會變得更加方便。在提案的最後，作者給出了許多第三方庫在合併字典時採用新方式編寫的例子，可謂是簡潔了不少。詳見 https://www.python.org/dev/peps/pep-0584/#id50 。

參考資料

[1]

PEP584: https://www.python.org/dev/peps/pep-0584/

[2]

Python 3.9.0a4: https://www.python.org/downloads/release/python-390a4/

優質文章，推薦閱讀：

如何高效地遠程部署？自動化運維利器 Fabric 教程

一份可以令 Python 變快的工具清單

Python 設計和歷史的 27 個問題

Python 工匠：高效操作文件的三個建議

感謝創作者的好文

PEP 584：字典合併操作符來了

一、前言

二、背景

2.1 dict.update

2.2 {d1, d2}

2.3 collections.ChainMap

2.4 dict(d1, **d2)

三、原理

四、規範

五、主流觀點

5.1 字典合併不符合交換律

5.2 字典合併並不高效

5.3 字典合併是有損的

5.4 只有一種方法達到目的

5.5 超過一種方法達到目的

5.6 字典合併讓代碼更難理解

5.7 參考下完整的集合API

六、已拒絕的觀點

七、實現

7.1 純 Python 實現

7.2 CPython 實現

八、總結

參考資料

《Python進階》學習筆記

Leetcode 3161. 物塊放置查詢

leetcode 60 排列序列

一個docker容器暴露多個端口

微服務實踐之使用 Visual Studio 2022 調試Dapr 應用程序

wpf附加屬性理解 WPF附加屬性

Python 到底是強類型語言，還是弱類型語言？

Python 工匠：在邊界處思考

Python 3.10 的首個 PEP 誕生，內置類型 zip() 將迎來新特性

OrderedDict 是如何保證 Key 的插入順序的？

Python 項目提速技巧：連接複用

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

PEP 584：字典合併操作符來了

一、前言

二、背景

2.1 dict.update

2.2 {**d1, **d2}

2.3 collections.ChainMap

2.4 dict(d1, **d2)

三、原理

四、規範

五、主流觀點

5.1 字典合併不符合交換律

5.2 字典合併並不高效

5.3 字典合併是有損的

5.4 只有一種方法達到目的

5.5 超過一種方法達到目的

5.6 字典合併讓代碼更難理解

5.7 參考下完整的集合API

六、已拒絕的觀點

七、實現

7.1 純 Python 實現

7.2 CPython 實現

八、總結

參考資料

2.2 {d1, d2}