為什麼繼承 Python 内置類型會出問題？！

本文出自“Python為什麼”系列，請檢視 全部文章

不久前，

Python貓

給大家推薦了一本書《流暢的Python》（

點選可跳轉閱讀

），那篇文章有比較多的“溢美之詞”，顯得比較空泛……

但是，《流暢的Python》一書值得反複回看，可以溫故知新。最近我偶然翻到書中一個有點詭異的知識點，是以準備來聊一聊這個話題——子類化内置類型可能會出問題？！

1、内置類型有哪些？

在正式開始之前，我們首先要科普一下：哪些是 Python 的内置類型？

根據官方文檔的分類，内置類型（Built-in Types）主要包含如下内容：

詳細文檔：

https://docs.python.org/3/library/stdtypes.html

其中，有大家熟知的

數字類型

、序列類型、文本類型、映射類型等等，當然還有我們之前介紹過的

布爾類型

、

...對象

等等。

在這麼多内容裡，本文隻關注那些作為

可調用對象

（callable）的内置類型，也就是跟内置函數（built-in function）在表面上相似的那些：int、str、list、tuple、range、set、dict……

這些類型（type）可以簡單了解成其它語言中的類（class），但是 Python 在此并沒有用習慣上的大駝峰命名法，是以容易讓人産生一些誤解。

在 Python 2.2 之後，這些内置類型可以被子類化（subclassing），也就是可以被繼承（inherit）。

2、内置類型的子類化

衆所周知，對于某個普通對象 x，Python 中求其長度需要用到公共的内置函數 len(x)，它不像 Java 之類的面向對象語言，後者的對象一般擁有自己的 x.length() 方法。（PS：關于這兩種設計風格的分析，推薦閱讀

這篇文章

）

現在，假設我們要定義一個清單類，希望它擁有自己的 length() 方法，同時保留普通清單該有的所有特性。

實驗性的代碼如下（僅作示範）：

# 定義一個list的子類
class MyList(list):
    def length(self):
        return len(self)           

我們令 MyList這個自定義類繼承 list，同時新定義一個 length() 方法。這樣一來，MyList 就擁有 append()、pop() 等等方法，同時還擁有 length() 方法。

# 添加兩個元素
ss = MyList()
ss.append("Python")
ss.append("貓")

print(ss.length())   # 輸出：2           

前面提到的其它内置類型，也可以這樣作子類化，應該不難了解。

順便發散一下，内置類型的子類化有何好處/使用場景呢？

有一個很直覺的例子，當我們在自定義的類裡面，需要頻繁用到一個清單對象時（給它添加/删除元素、作為一個整體傳遞……），這時候如果我們的類繼承自 list，就可以直接寫 self.append()、self.pop()，或者将 self 作為一個對象傳遞，進而不用額外定義一個清單對象，在寫法上也會簡潔一些。

還有其它的好處/使用場景麼？歡迎大家留言讨論~~

3、内置類型子類化的“問題”

終于要進入本文的正式主題了:)

通常而言，在我們教科書式的認知中，子類中的方法會覆寫父類的同名方法，也就是說，子類方法的查找優先級要高于父類方法。

下面看一個例子，父類 Cat，子類 PythonCat，都有一個 say() 方法，作用是說出目前對象的 inner_voice：

# Python貓是一隻貓
class Cat():
    def say(self):
        return self.inner_voice()
    def inner_voice(self):
        return "喵"
class PythonCat(Cat):
    def inner_voice(self):
        return "喵喵"           

當我們建立子類 PythonCat 的對象時，它的 say() 方法會優先取到自己定義出的 inner_voice() 方法，而不是 Cat 父類的 inner_voice() 方法：

my_cat = PythonCat()
# 下面的結果符合預期
print(my_cat.inner_voice()) # 輸出：喵喵
print(my_cat.say())         # 輸出：喵喵           

這是程式設計語言約定俗成的慣例，是一個基本原則，學過面向對象程式設計基礎的同學都應該知道。

然而，當 Python 在實作繼承時，似乎不完全會按照上述的規則運作。它分為兩種情況：

• 符合常識：對于用 Python 實作的類，它們會遵循“子類先于父類”的原則
• 違背常識：對于實際是用 C 實作的類（即str、list、dict等等這些内置類型），在顯式調用子類方法時，會遵循“子類先于父類”的原則；但是，在存在隐式調用時，它們似乎會遵循“父類先于子類”的原則，即通常的繼承規則會在此失效

對照 PythonCat 的例子，相當于說，直接調用 my_cat.inner_voice() 時，會得到正确的“喵喵”結果，但是在調用 my_cat.say() 時，則會得到超出預期的“喵”結果。

下面是《流暢的Python》中給出的例子（12.1章節）：

class DoppelDict(dict): 
    def __setitem__(self, key, value): 
        super().__setitem__(key, [value] * 2)

dd = DoppelDict(one=1)  # {'one': 1}
dd['two'] = 2           # {'one': 1, 'two': [2, 2]}
dd.update(three=3)      # {'three': 3, 'one': 1, 'two': [2, 2]}           

在這個例子中，dd['two'] 會直接調用子類的__setitem__()方法，是以結果符合預期。如果其它測試也符合預期的話，最終結果會是{'three': [3, 3], 'one': [1, 1], 'two': [2, 2]}。

然而，初始化和 update() 直接調用的分别是從父類繼承的__init__()和__update__()，再由它們隐式地調用__setitem__()方法，此時卻并沒有調用子類的方法，而是調用了父類的方法，導緻結果超出預期！

官方 Python 這種實作雙重規則的做法，有點違背大家的常識，如果不加以注意，搞不好就容易踩坑。

那麼，為什麼會出現這種例外的情況呢？

4、内置類型的方法的真面目

我們知道了内置類型不會隐式地調用子類覆寫的方法，接着，就是

Python貓

的刨根問底時刻：為什麼它不去調用呢？

《

流暢的Python

》書中沒有繼續追問，不過，我試着胡亂猜測一下（應該能從源碼中得到驗證）：内置類型的方法都是用 C 語言實作的，事實上它們彼此之間并不存在着互相調用，是以就不存在調用時的查找優先級問題。

也就是說，前面的“__init__()和__update__()會隐式地調用__setitem__()方法”這種說法并不準确！

這幾個魔術方法其實是互相獨立的！__init__()有自己的 setitem 實作，并不會調用父類的__setitem__()，當然跟子類的__setitem__()就更沒有關系了。

從邏輯上了解，字典的__init__()方法中包含__setitem__()的功能，是以我們以為前者會調用後者，這是慣性思維的展現，然而實際的調用關系可能是這樣的：

左側的方法打開語言界面之門進入右側的世界，在那裡實作它的所有使命，并不會折傳回原始界面查找下一步的指令（即不存在圖中的紅線路徑）。不折返的原因很簡單，即 C 語言間代碼調用效率更高，實作路徑更短，實作過程更簡單。

同理，dict 類型的 get() 方法與__getitem__()也不存在調用關系，如果子類隻覆寫了__getitem__()的話，當子類調用 get() 方法時，實際會使用到父類的 get() 方法。（PS：關于這一點，《流暢的Python》及 PyPy 文檔的描述都不準确，它們誤以為 get() 方法會調用__getitem__()）

也就是說，Python 内置類型的方法本身不存在調用關系，盡管它們在底層 C 語言實作時，可能存在公共的邏輯或能被複用的方法。

我想到了“

Python為什麼

”系列曾分析過的《

Python 為什麼能支援任意的真值判斷？

》。在我們寫

if xxx

時，它似乎會隐式地調用__bool__()和__len__()魔術方法，然而實際上程式依據 POP_JUMP_IF_FALSE 指令，會直接進入純 C 代碼的邏輯，并不存在對這倆魔術方法的調用！

是以，在意識到 C 實作的特殊方法間互相獨立之後，我們再回頭看内置類型的子類化，就會有新的發現：

父類的__init__()魔術方法會打破語言界面實作自己的使命，然而它跟子類的__setitem__()并不存在通路，即圖中紅線路徑不可達。

特殊方法間各行其是，由此，我們會得出跟前文不同的結論：實際上 Python 嚴格遵循了“子類方法先于父類方法”繼承原則，并沒有破壞常識！

最後值得一提的是，__missing__()是一個特例。《流暢的Python》僅僅簡單而含糊地寫了一句，沒有過多展開。

經過初步實驗，我發現當子類定義了此方法時，get() 讀取不存在的 key 時，正常傳回 None；但是 __getitem__() 和 dd['xxx'] 讀取不存在的 key 時，都會按子類定義的__missing__()進行處理。

我還沒空深入分析，懇請知道答案的同學給我留言。

5、内置類型子類化的最佳實踐

綜上所述，内置類型子類化時并沒有出問題，隻是由于我們沒有認清特殊方法（C 語言實作的方法）的真面目，才會導緻結果偏差。

那麼，這又召喚出了一個新的問題：如果非要繼承内置類型，最佳的實踐方式是什麼呢？

首先，如果在繼承内置類型後，并不重寫（overwrite）它的特殊方法的話，子類化就不會有任何問題。

其次，如果繼承後要重寫特殊方法的話，記得要把所有希望改變的方法都重寫一遍，例如，如果想改變 get() 方法，就要重寫 get() 方法，如果想改變 __getitem__()方法，就要重寫它……

但是，如果我們隻是想重寫某種邏輯（即 C 語言的部分），以便所有用到該邏輯的特殊方法都發生改變的話，例如重寫__setitem__()的邏輯，同時令初始化和update()等操作跟着改變，那麼該怎麼辦呢？

我們已知特殊方法間不存在複用，也就是說單純定義新的__setitem__()是不夠的，那麼，怎麼才能對多個方法同時産生影響呢？

PyPy 這個非官方的 Python 版本發現了這個問題，它的做法是令内置類型的特殊方法發生調用，建立它們之間的連接配接通路。

官方 Python 當然也意識到了這麼問題，不過它并沒有改變内置類型的特性，而是提供出了新的方案：UserString、UserList、UserDict……

除了名字不一樣，基本可以認為它們等同于内置類型。

這些類的基本邏輯是用 Python 實作的，相當于是把前文 C 語言界面的某些邏輯搬到了 Python 界面，在左側建立起調用鍊，如此一來，就解決了某些特殊方法的複用問題。

對照前文的例子，采用新的繼承方式後，結果就符合預期了：

from collections import UserDict

class DoppelDict(UserDict):
    def __setitem__(self, key, value): 
        super().__setitem__(key, [value] * 2)

dd = DoppelDict(one=1)  # {'one': [1, 1]}
dd['two'] = 2           # {'one': [1, 1], 'two': [2, 2]}
dd.update(three=3)      # {'one': [1, 1], 'two': [2, 2], 'three': [3, 3]}           

顯然，如果要繼承 str/list/dict 的話，最佳的實踐就是繼承

collections

庫提供的那幾個類。

6、小結

寫了這麼多，是時候作 ending 了~~

在本系列的前一篇文章中，Python貓從查找順序與運作速度兩方面，分析了“

為什麼内置函數/内置類型不是萬能的

”，本文跟它一脈相承，也是揭示了内置類型的某種神秘的看似是缺陷的行為特征。

本文雖然是從《流暢的Python》書中獲得的靈感，然而在語言表象之外，我們還多追問了一個“為什麼”，進而更進一步地分析出了現象背後的原理。

簡而言之，内置類型的特殊方法是由 C 語言獨立實作的，它們在 Python 語言界面中不存在調用關系，是以在内置類型子類化時，被重寫的特殊方法隻會影響該方法本身，不會影響其它特殊方法的效果。

如果我們對特殊方法間的關系有錯誤的認知，就可能會認為 Python 破壞了“子類方法先于父類方法”的基本繼承原則。（很遺憾《流暢的Python》和 PyPy 都有此錯誤的認知）

為了迎合大家對内置類型的普遍預期，Python 在标準庫中提供了 UserString、UserList、UserDict 這些擴充類，友善程式員來繼承這些基本的資料類型。

寫在最後：本文屬于“

”系列（Python貓出品），該系列主要關注 Python 的文法、設計和發展等話題，以一個個“為什麼”式的問題為切入點，試着展現 Python 的迷人魅力。若你有其它感興趣的話題，歡迎填在《

Python的十萬個為什麼？

》裡的調查問卷中。