先從一個(gè)很基礎(chǔ)的問題說起[1] [2]這行代碼Python 是怎么知道要返回[1, 2]的你可能會(huì)說這是語(yǔ)法層面的加法列表本來(lái)就能相加。但再往深一層想這個(gè)“本來(lái)能相加”的能力并不像 C 那樣由編譯器針對(duì)內(nèi)置類型寫死而是被設(shè)計(jì)成了一套“協(xié)議約定”。在 Python 里這種約定靠的是一組以雙下劃線開頭和結(jié)尾的方法也就是大家常說的魔術(shù)方法dunder method。寫過一段時(shí)間 Python 的人基本都會(huì)用__init__但很少有人能把這一整套雙下劃線方法講清楚。我在剛?cè)胄袝r(shí)也有同樣的困惑為什么 Python 不像 Java 那樣萬(wàn)物皆方法非要搞出len(obj)這種看起來(lái)像全局函數(shù)的東西后來(lái)讀了一些內(nèi)部實(shí)現(xiàn)相關(guān)的資料才明白雙下劃線方法不是某種語(yǔ)法裝飾而是 Python 整個(gè)對(duì)象系統(tǒng)的地基。它決定了你的自定義類能不能被len()調(diào)用、能不能用for遍歷、能不能被放進(jìn)set、能不能用with管理、能不能像函數(shù)一樣執(zhí)行。這篇文章我就把這套東西從頭到尾拆開聊一遍包括每個(gè)方法什么時(shí)候被調(diào)用、怎么實(shí)現(xiàn)、有哪些坑以及我實(shí)際排錯(cuò)時(shí)積累的一些經(jīng)驗(yàn)。這篇文章適合兩類人一類是已經(jīng)會(huì)寫基礎(chǔ) Python、但想真正理解“對(duì)象協(xié)議”的開發(fā)者另一類是正在設(shè)計(jì)自己模塊或類庫(kù)、希望自定義類能和內(nèi)置類型一樣好用的同學(xué)。我會(huì)用大量可運(yùn)行的代碼示例盡量讓每個(gè)結(jié)論都能直接落地上手。1. 魔術(shù)方法不是魔法Python 為什么要把接口約定藏在雙下劃線后面1.1 從len(obj)而不是obj.len()說起在所有編程語(yǔ)言里Python 算是少數(shù)幾個(gè)“內(nèi)置函數(shù) 特殊方法”雙重結(jié)構(gòu)的語(yǔ)言。你用len(abc)、len([1,2,3])甚至len(自定義對(duì)象)都能得到長(zhǎng)度換成 Java你得在類里自己寫size()再用obj.size()去調(diào)。這兩種設(shè)計(jì)沒有絕對(duì)優(yōu)劣但 Python 這種方案有一個(gè)非常隱秘的優(yōu)點(diǎn)它把“一個(gè)對(duì)象應(yīng)該具備什么能力”這件事從“繼承自某個(gè)基類”解耦成了“實(shí)現(xiàn)了某個(gè)協(xié)議”。舉個(gè)例子Python 的len()在 CPython 內(nèi)部本質(zhì)上做的事情差不多是這樣的先檢查傳入對(duì)象的類型然后在類型對(duì)象上查找名為__len__的方法。如果找到了就調(diào)用它并返回結(jié)果找不到就拋出TypeError: object of type XXX has no len()。換句話說len()不是一個(gè)真正意義上的全局函數(shù)而是一個(gè)“協(xié)議入口”。只要你的類實(shí)現(xiàn)了__len__不需要繼承任何框架基類它就是 Sized 協(xié)議的一員。這種設(shè)計(jì)的影響很深遠(yuǎn)。你在寫代碼時(shí)不需要關(guān)心傳入的到底是一個(gè)list、dict、str還是某個(gè)第三方庫(kù)里的自定義集合只要它實(shí)現(xiàn)了__len__len()就一定能用。這正是 Python “鴨子類型”哲學(xué)的底層支撐不看對(duì)象是什么類只看它能不能響應(yīng)這個(gè)操作。1.2 雙下劃線到底在防什么新手常問為什么這些方法的名字非要長(zhǎng)得這么丑前后各加兩個(gè)下劃線這其實(shí)是一個(gè)“既防沖突又防誤用”的設(shè)計(jì)。先說防沖突。Python 的類里可以有成千上萬(wàn)個(gè)普通方法名如果特殊方法叫init、len、add很容易和用戶自己的業(yè)務(wù)方法撞車。一旦撞上解釋器行為就會(huì)變得不可預(yù)期。加上雙下劃線之后“系統(tǒng)協(xié)議”和“用戶方法”在命名空間上被天然隔開了。比如你在類里定義一個(gè)add(self, x)方法那純粹是業(yè)務(wù)方法不會(huì)影響運(yùn)算符但如果你定義的是__add__(self, other)那這個(gè)對(duì)象就可以被操作。這個(gè)區(qū)別非常重要我見過有同事在自定義類里寫了add方法然后試圖用obj1 obj2去觸發(fā)它結(jié)果得到一個(gè)TypeError后來(lái)排查半天才發(fā)現(xiàn)方法名寫錯(cuò)了。再說防誤用。雙下劃線前綴在 Python 的語(yǔ)法里還有一層含義類內(nèi)部的__name形式的成員會(huì)被“名稱改寫”name mangling變成_ClassName__name。雖然__init__這種雙下劃線開頭且結(jié)尾的魔法方法不會(huì)觸發(fā)改寫規(guī)則但雙下劃線前綴本身已經(jīng)傳遞了一個(gè)信號(hào)“這是解釋器預(yù)留的協(xié)議不是在正常業(yè)務(wù)代碼里應(yīng)該頻繁手動(dòng)調(diào)用的東西?！蹦惝?dāng)然可以顯式調(diào)用obj.__len__()但絕大多數(shù)場(chǎng)景下你應(yīng)該寫len(obj)。這一層“防誤用”的意圖既是設(shè)計(jì)哲學(xué)也是寫代碼時(shí)的可讀性約定。為了便于理解可以把這套機(jī)制類比成充電接口標(biāo)準(zhǔn)。USB-C 接口規(guī)定了引腳怎么排列、怎么握手充電頭不用關(guān)心對(duì)面是手機(jī)還是耳機(jī)Python 的魔術(shù)方法就是“協(xié)議引腳”len()、、for、with這些語(yǔ)法和內(nèi)置函數(shù)是“充電頭”。只要你的對(duì)象按照協(xié)議把引腳做出來(lái)任何通用入口都能直接驅(qū)動(dòng)它。這就是為什么說掌握了魔術(shù)方法等于真正掌握了“如何讓自定義對(duì)象融入 Python 生態(tài)”。下面我用一張表把日常最常用的協(xié)議入口和觸發(fā)場(chǎng)景梳理清楚后面章節(jié)會(huì)逐個(gè)展開。語(yǔ)法或內(nèi)置函數(shù)觸發(fā)的方法典型使用場(chǎng)景l(fā)en(obj)obj.__len__()容器類、集合類obj[i]/obj[i] vobj.__getitem__()/obj.__setitem__()序列、映射、自定義容器for x in objobj.__iter__()obj.__next__()可迭代對(duì)象、迭代器x in objobj.__contains__()成員判斷obj otherobj.__add__(other)運(yùn)算重載str(obj)/print(obj)obj.__str__()用戶可讀輸出repr(obj)obj.__repr__()開發(fā)者調(diào)試輸出with obj as x:obj.__enter__()/obj.__exit__()資源管理obj()obj.__call__()可調(diào)用對(duì)象、函數(shù)式編程bool(obj)/if obj:obj.__bool__()真值判斷2. 從零手寫一個(gè)“活成原生類型”的對(duì)象成績(jī)單類的完整實(shí)現(xiàn)概念講多了容易飄這一節(jié)我直接帶你手寫一個(gè)類。定義一個(gè)大學(xué)的成績(jī)單對(duì)象ScoreReport它需要能計(jì)算總成績(jī)、比較兩個(gè)成績(jī)單的高低、可以把兩個(gè)成績(jī)單合并、可以用for遍歷每次考試成績(jī)、可以判斷某門課在不在成績(jī)單里、還能被len()和bool()調(diào)用。我故意選這個(gè)稍微綜合的場(chǎng)景是因?yàn)樗馨炎畛Ｒ姷哪g(shù)方法一次性串起來(lái)而不是每講一個(gè)方法就造一個(gè)沒意義的玩具類。2.1 初始化與展示__init__、__repr__、__str__class ScoreReport: def __init__(self, owner, scoresNone): self.owner owner # 這里用 list(scores or []) 而不是直接賦值避免多個(gè)實(shí)例共享同一個(gè)可變 list self.scores list(scores or []) def __repr__(self): return fScoreReport(owner{self.owner!r}, scores{self.scores!r}) def __str__(self): course_str , .join(f{name}:{score} for name, score in self.scores) return f{self.owner} 的成績(jī)單{course_str}先說一個(gè)最重要的坑__init__里的list(scores or [])是必須的不能寫成self.scores scores or []。如果直接把參數(shù)列表賦值給實(shí)例屬性那么兩個(gè)不同的ScoreReport可能會(huì)共享同一個(gè)底層列表一個(gè)實(shí)例改了數(shù)據(jù)另一個(gè)也跟著變。這個(gè)坑表面上是列表引用問題本質(zhì)上是你寫類時(shí)的可變對(duì)象復(fù)制意識(shí)。接下來(lái)看__repr__和__str__的區(qū)別。這兩個(gè)方法平時(shí)容易混但它們面向的對(duì)象完全不同__repr__是給開發(fā)者看的它的目標(biāo)是在異常、日志、IDE 調(diào)試器里讓你一眼看穿這個(gè)對(duì)象的內(nèi)部結(jié)構(gòu)。理想情況下repr(obj)的返回值應(yīng)該能直接重建一個(gè)等價(jià)對(duì)象所以我在里面用了!r格式符保證字符串內(nèi)容帶引號(hào)這樣ScoreReport(owner張三, scores[...])可以直接被eval解析。__str__是給最終用戶看的print(obj)和str(obj)會(huì)優(yōu)先調(diào)用它。它不需要能重建對(duì)象但應(yīng)該讓用戶讀起來(lái)舒服。這里有個(gè)非常實(shí)用的細(xì)節(jié)如果只實(shí)現(xiàn)了__repr__沒實(shí)現(xiàn)__str__print(obj)也會(huì)退回去調(diào)用__repr__。反之則不行。所以我個(gè)人的習(xí)慣是永遠(yuǎn)先寫__repr__它是調(diào)試底線當(dāng)需要面向用戶輸出時(shí)再補(bǔ)__str__。2.2 讓對(duì)象有長(zhǎng)度和真值__len__與__bool__def __len__(self): return len(self.scores) def __bool__(self): return bool(self.scores)實(shí)現(xiàn)__len__后len(score_report)就能用了。很多人不知道的是__len__還關(guān)系到一個(gè)隱藏行為如果你沒有定義__bool__Python 會(huì)退化成len(obj) 0來(lái)判斷真假。這就是為什么空列表、空字典、空字符串在if條件里是False——它們都實(shí)現(xiàn)了__len__而長(zhǎng)度為 0 時(shí)會(huì)被當(dāng)成假值。一旦自己實(shí)現(xiàn)了__bool__這個(gè)退化機(jī)制就被覆蓋了。在上面的例子里成績(jī)單里哪怕有一門課成績(jī)?yōu)?0bool()也返回True因?yàn)閇(數(shù)學(xué), 0)]這個(gè)列表非空。如果業(yè)務(wù)邏輯認(rèn)為“沒有有效成績(jī)才是空”你可以把這個(gè)判斷寫在__bool__里做更精細(xì)的控制。2.3 比較和運(yùn)算__eq__與__lt__、__add__def __eq__(self, other): if not isinstance(other, ScoreReport): return NotImplemented return self.owner other.owner and self.scores other.scores def __lt__(self, other): if not isinstance(other, ScoreReport): return NotImplemented return sum(score for _, score in self.scores) sum(score for _, score in other.scores) def __add__(self, other): if not isinstance(other, ScoreReport): return NotImplemented return ScoreReport( ownerself.owner other.owner, scoresself.scores other.scores, )關(guān)于__eq__我最想強(qiáng)調(diào)的一點(diǎn)是不要在一個(gè)不匹配的類型面前直接返回False而是應(yīng)該返回NotImplemented。很多初學(xué)者會(huì)寫成def __eq__(self, other): return self.owner other.owner and self.scores other.scores當(dāng)other是一個(gè)整數(shù)或字符串時(shí)這段代碼會(huì)拋AttributeError因?yàn)閕nt沒有owner這個(gè)屬性。而返回NotImplemented的意思是“我不擅長(zhǎng)和這個(gè)類型比較請(qǐng)你讓對(duì)方也試試如果對(duì)方也拒絕Python 才會(huì)兜底返回False?！蓖瑯拥豞_lt__返回NotImplemented是為了支持反向比較比如a b實(shí)際會(huì)嘗試b a。實(shí)現(xiàn)了__lt__之后sorted([s1, s2, s3])就能直接用因?yàn)榕判蛩惴ㄖ恍枰馈罢l(shuí)小于誰(shuí)”。如果以后還需要、、Python 會(huì)自動(dòng)從__lt__推導(dǎo)出部分比較結(jié)果但你也可以顯式實(shí)現(xiàn)__gt__等方法來(lái)精確控制。__add__的設(shè)計(jì)也要多說一句我在返回值里直接創(chuàng)建了一個(gè)新的ScoreReport而不是修改self。這是符合直覺的——運(yùn)算在語(yǔ)義上應(yīng)該是“生成一個(gè)新對(duì)象”而不是原地修改舊對(duì)象。如果你希望支持s1 s2這種原地操作可以單獨(dú)實(shí)現(xiàn)__iadd__。2.4 迭代與成員判斷__iter__、__next__、__contains__、__getitem__def __iter__(self): # 注意這里為了演示故意用一個(gè)游標(biāo)屬性 self._idx 0 return self def __next__(self): if self._idx len(self.scores): raise StopIteration value self.scores[self._idx] self._idx 1 return value def __contains__(self, item): return any(course item for course, _ in self.scores) def __getitem__(self, index): return self.scores[index]迭代器協(xié)議是很多新手卡殼的地方。__iter__必須返回一個(gè)迭代器對(duì)象這個(gè)迭代器對(duì)象要有__next__方法。我在例子里直接讓ScoreReport自己充當(dāng)了迭代器這是一種簡(jiǎn)寫但要注意它的副作用對(duì)象內(nèi)部多了一個(gè)_idx游標(biāo)狀態(tài)如果同一個(gè)對(duì)象被兩個(gè)for循環(huán)嵌套遍歷游標(biāo)會(huì)互相干擾出現(xiàn)很難排查的詭異行為。更穩(wěn)妥的做法是單獨(dú)寫一個(gè)迭代器類或者直接讓__iter__返回生成器def __iter__(self): for course, score in self.scores: yield course, score這段代碼更符合實(shí)際工程里的寫法。把__iter__寫成生成器函數(shù)之后for name, score in report:就能像遍歷列表一樣遍歷成績(jī)單。__contains__是in操作符的底層實(shí)現(xiàn)。如果沒寫__contains__Python 會(huì)退化為逐個(gè)調(diào)用__iter__遍歷查找再不行就退回用__getitem__從下標(biāo) 0 開始逐個(gè)取直到拋IndexError。所以你會(huì)發(fā)現(xiàn)就算只實(shí)現(xiàn)了__getitem__不實(shí)現(xiàn)__iter__對(duì)象也能被for循環(huán)遍歷這是 Python 為了兼容舊式序列而保留的“退路協(xié)議”。但我建議不要依賴這個(gè)退路能用__iter__就用__iter__語(yǔ)義更清晰性能也更好。至于__getitem__它實(shí)現(xiàn)了下標(biāo)訪問report[0]同時(shí)因?yàn)樗祷氐氖莝cores的切片report[0:2]也能工作——列表切片會(huì)自動(dòng)轉(zhuǎn)發(fā)給__getitem__的slice參數(shù)這一點(diǎn)很多教程都講得不夠細(xì)。2.5 把成績(jī)單類放在一起看效果if __name__ __main__: s1 ScoreReport(張三, [(數(shù)學(xué), 88), (英語(yǔ), 92)]) s2 ScoreReport(李四, [(數(shù)學(xué), 95), (英語(yǔ), 80)]) print(repr(s1)) # ScoreReport(owner張三, scores[(數(shù)學(xué), 88), (英語(yǔ), 92)]) print(s1) # 張三 的成績(jī)單數(shù)學(xué):88, 英語(yǔ):92 print(len(s1)) # 2 print(bool(ScoreReport(空))) # False print(s1 s2) # False print(s1 s2) # False張三總分180 李四總分175 不對(duì)這里是180 175所以False print(s1 s2) # 張三 李四 的成績(jī)單數(shù)學(xué):88, 英語(yǔ):92, 數(shù)學(xué):95, 英語(yǔ):80 for course, score in s1: print(course, score) # 數(shù)學(xué) 88 / 英語(yǔ) 92 print(數(shù)學(xué) in s1) # True print(s1[1]) # (英語(yǔ), 92)一個(gè)自定義類通過這一組雙下劃線方法就獲得和內(nèi)置容器幾乎一樣的體驗(yàn)。這也是這篇文章里最重要的一段代碼建議你把它完整跑一遍觀察每個(gè)操作實(shí)際觸發(fā)了哪個(gè)方法。3. 最容易被坑的兩組對(duì)照初始化與析構(gòu)、屬性訪問的底層鏈路3.1__new__和__init__不是一回事很多教程會(huì)把__init__叫“構(gòu)造函數(shù)”這是不嚴(yán)謹(jǐn)?shù)?。真正的“?gòu)造”發(fā)生在__new__里它負(fù)責(zé)分配內(nèi)存并返回一個(gè)實(shí)例__init__只是在這個(gè)已經(jīng)存在的實(shí)例上做初始化。完整流程是先__new__后__init__而且有個(gè)非常重要的規(guī)則如果__new__返回的不是cls類型的實(shí)例__init__根本不會(huì)被調(diào)用。那實(shí)際寫代碼時(shí)什么時(shí)候要重寫__new__答案是場(chǎng)景很少但一旦遇到就必須用它。最典型的案例是單例模式class SingleConnection: _instance None def __new__(cls, *args, **kwargs): if cls._instance is None: cls._instance super().__new__(cls) return cls._instance重寫__new__時(shí)一定要返回super().__new__(cls)的結(jié)果否則創(chuàng)建出來(lái)的可能不是cls的實(shí)例導(dǎo)致后續(xù)邏輯全部錯(cuò)亂。另一個(gè)場(chǎng)景是繼承不可變類型比如你想寫一個(gè)元組子類在__init__里修改字段是無(wú)效的必須在__new__里做好全部處理——不可變類型的字段在__init__階段已經(jīng)不能改了。3.2__getattr__與__getattribute__屬性訪問的完整鏈路這兩個(gè)方法名字很像行為差異卻非常大。__getattribute__是一個(gè)無(wú)條件攔截器。只要訪問實(shí)例的任何屬性不管這個(gè)屬性存不存在都會(huì)先經(jīng)過它。__getattr__是一個(gè)兜底處理器。只有正常的屬性查找流程全部失敗之后它才會(huì)被調(diào)用?？匆欢未a就清楚了class Demo: def __init__(self): self.name demo def __getattribute__(self, name): print(getattribute called:, name) return super().__getattribute__(name) def __getattr__(self, name): return ffallback: {name} d Demo() print(d.name) # 先打印 getattribute called: name再打印 demo print(d.not_exist) # 先打印 getattribute called: not_exist再打印 fallback: not_exist看到?jīng)]有即使是訪問一個(gè)不存在的屬性也會(huì)先調(diào)__getattribute__查找失敗后才落到__getattr__。這解釋了為什么在__getattr__里“安全地”訪問self.xxx有時(shí)會(huì)出問題如果self.xxx本身不存在并且你在這個(gè)方法里又寫了self.xxx就會(huì)形成一個(gè)隱形的遞歸循環(huán)。正確的做法是直接操作self.__dict__或者調(diào)用object.__getattribute__(self, name)來(lái)繞過這個(gè)兜底邏輯。__getattr__最有實(shí)用價(jià)值的場(chǎng)景是“懶加載”。比如你在讀取后端的 JSON 配置時(shí)希望把config[database][host]變成config.database.host又不想為每個(gè)字段手寫屬性class AttrDict: def __init__(self, data): self.__dict__[_data] data def __getattr__(self, name): try: value self._data[name] except KeyError: raise AttributeError(name) if isinstance(value, dict): return AttrDict(value) return value這里我把原始字典存在self.__dict__[_data]而不是self._data data就是為了避免self._data的訪問觸發(fā)__getattr__從而造成遞歸。這個(gè) trick 非常實(shí)用建議記下來(lái)。3.3__setattr__與__delattr__賦值和刪除也不是省油的燈和讀屬性對(duì)應(yīng)寫操作也有兩個(gè)鉤子__setattr__在self.xxx yyy時(shí)觸發(fā)__delattr__在del self.xxx時(shí)觸發(fā)。一個(gè)經(jīng)典的應(yīng)用是做不可變對(duì)象或者字段校驗(yàn)class ValidatedScore: def __setattr__(self, name, value): if name score and not (0 value 100): raise ValueError(score must be between 0 and 100) super().__setattr__(name, value)不過這里最大的坑是在__setattr__內(nèi)部如果寫self.score value會(huì)再次觸發(fā)__setattr__陷入無(wú)限遞歸。正確的姿勢(shì)是用super().__setattr__(name, value)或者直接寫self.__dict__[name] value。3.4 改了__eq__卻忘了__hash__字典和集合里的幽靈問題Python 有一個(gè)非常硬性的約定兩個(gè)對(duì)象如果相等a b為True那么它們的哈希值必須相等hash(a) hash(b)。這個(gè)約定的底層邏輯是set和dict的實(shí)現(xiàn)原理它們先通過哈希值定位到“桶”再用比較桶里的對(duì)象。如果兩個(gè)相等對(duì)象哈希不同它們會(huì)被放進(jìn)不同的桶導(dǎo)致查找永久失敗。麻煩的地方在于當(dāng)你自定義了__eq__之后Python 會(huì)自動(dòng)把該類的__hash__設(shè)為None對(duì)象就變成“不可哈?！绷恕２恍拍阍囋嘽lass Person: def __init__(self, name): self.name name def __eq__(self, other): return isinstance(other, Person) and self.name other.name p Person(張三) hash(p) # TypeError: unhashable type: Person這是 Python 的自我保護(hù)機(jī)制它知道你重定義了相等語(yǔ)義但不知道你的相等邏輯是否基于可變字段所以它不敢再默認(rèn)按對(duì)象 id 計(jì)算哈希。如果你確定這個(gè)對(duì)象在哈希表生命周期內(nèi)不會(huì)被修改可以顯式補(bǔ)上def __hash__(self): return hash(self.name)這里隱含的另一個(gè)教訓(xùn)是如果你用一個(gè)可變對(duì)象作為dict的 key那么這個(gè)對(duì)象一旦被修改哈希值就變了之后你再按原來(lái)的 key 去查永遠(yuǎn)找不到。所以被放進(jìn)set和dict的對(duì)象的參與哈希的字段必須是不可變的。3.5 別把__del__當(dāng) C 析構(gòu)函數(shù)用最后一個(gè)容易引起誤解的是__del__。在 CPython 里它確實(shí)會(huì)在對(duì)象的引用計(jì)數(shù)歸零時(shí)被調(diào)用但你不能依賴它在確定的時(shí)間點(diǎn)執(zhí)行。原因有兩點(diǎn)一是引用計(jì)數(shù)只適用于 CPython換成 PyPy 這類解釋器回收時(shí)機(jī)完全不同二是循環(huán)引用會(huì)導(dǎo)致對(duì)象進(jìn)入垃圾回收器gc模塊的待處理列表__del__的執(zhí)行會(huì)被推遲到 GC 真正清理的時(shí)機(jī)。所以如果你寫def __del__(self): self.file.close()這在很多情況下都沒問題但進(jìn)程退出時(shí)如果還有對(duì)象沒被回收文件可能不會(huì)被優(yōu)雅關(guān)閉。正確的資源管理方式是配合with語(yǔ)句使用上下文管理器也就是下一章要講的__enter__和__exit__。__del__更適合作為“最后的保底清理”而不是主力資源釋放手段。4. 讓對(duì)象從“能跑”到“好用”上下文管理、下標(biāo)訪問與可調(diào)用對(duì)象4.1__enter__和__exit__把資源管理變成語(yǔ)法級(jí)承諾with open(file.txt) as f:是 Python 里最常用的資源管理方式而它的底層就是__enter__和__exit__。任何實(shí)現(xiàn)了這兩個(gè)方法的對(duì)象都可以被with語(yǔ)句接管。__enter__的返回值會(huì)成為as后面的變量__exit__在代碼塊結(jié)束后必定被調(diào)用不管代碼塊內(nèi)部有沒有拋異常。一個(gè)常見的實(shí)戰(zhàn)場(chǎng)景是“自動(dòng)計(jì)時(shí)器”import time class Timer: def __enter__(self): self.start time.perf_counter() return self def __exit__(self, exc_type, exc_val, exc_tb): self.elapsed time.perf_counter() - self.start print(f執(zhí)行耗時(shí): {self.elapsed:.4f}s) with Timer(): total sum(range(1_000_000))__exit__有四個(gè)參數(shù)exc_type、exc_val、exc_tb分別對(duì)應(yīng)異常類型、異常實(shí)例、異常 traceback。如果代碼塊里沒有異常這三個(gè)參數(shù)都是None。如果你想讓with塊吞掉某個(gè)異常通常不推薦讓__exit__返回True即可異常會(huì)被靜默處理返回None或False異常繼續(xù)向上傳播。這個(gè)機(jī)制非常適合做數(shù)據(jù)庫(kù)事務(wù)?？梢栽赺_enter__里開啟事務(wù)__exit__里根據(jù)有沒有異常決定commit還是rollback。這也是為什么 ORM 和數(shù)據(jù)庫(kù)驅(qū)動(dòng)幾乎都提供上下文管理器接口的原因。4.2__getitem__和__setitem__讓對(duì)象像列表和字典一樣可讀寫我在第 2 章已經(jīng)實(shí)現(xiàn)了__getitem__這一節(jié)把它的機(jī)制徹底說透。obj[key]會(huì)被 Python 翻譯成type(obj).__getitem__(obj, key)。注意這里的查找是按類型進(jìn)行的不是直接在對(duì)象上找。這也是為什么給某個(gè)實(shí)例單獨(dú)掛載一個(gè)__getitem__屬性不會(huì)生效因?yàn)樗绊懖涣祟愋偷牟樵兟窂?。__getitem__不僅能接收整數(shù)下標(biāo)還能接收slice對(duì)象和任意 keyclass MultiIndex: def __getitem__(self, key): if isinstance(key, slice): return fslice from {key.start} to {key.stop} return fsingle key: {key} m MultiIndex() print(m[1]) # single key: 1 print(m[1:3]) # slice from 1 to 3配合__setitem__、__delitem__后對(duì)象就能像一個(gè)“行為可控的字典”你可以在賦值時(shí)做類型檢查可以在刪除時(shí)觸發(fā)清理回調(diào)甚至可以實(shí)現(xiàn)類似“帶默認(rèn)值的字典”的效果。4.3__call__讓實(shí)例擁有函數(shù)的能力在 Python 里函數(shù)是一等公民但有時(shí)候你需要一個(gè)“帶狀態(tài)的函數(shù)”。這時(shí)讓你的對(duì)象實(shí)現(xiàn)__call__它就能像普通函數(shù)一樣被調(diào)用。class Adder: def __init__(self, n): self.n n def __call__(self, x): return x self.n add_5 Adder(5) print(add_5(3)) # 8這里add_5是一個(gè)對(duì)象但它可以像函數(shù)一樣使用。這種模式在幾種場(chǎng)景下特別好用策略模式把不同的處理邏輯封裝成可調(diào)用對(duì)象互相替換。裝飾器工廠實(shí)現(xiàn)一個(gè)帶參數(shù)的裝飾器?；卣{(diào)函數(shù)給框架傳入一個(gè)帶__call__的實(shí)例它既能執(zhí)行邏輯又能保存中間狀態(tài)。一個(gè)更進(jìn)階的用途是讓類本身“可配置”。你在__init__里存好參數(shù)__call__里執(zhí)行主邏輯然后把這個(gè)對(duì)象丟給高層框架?？蚣懿魂P(guān)心它到底是不是函數(shù)只要能調(diào)用就行這就是接口與具體實(shí)現(xiàn)的解耦。4.4__contains__、__iter__和__getitem__的優(yōu)先級(jí)關(guān)系很多人在寫自定義容器時(shí)會(huì)困惑in操作到底觸發(fā)哪個(gè)方法其實(shí) Python 的查找順序非常明確先找__contains__找到了直接用它判斷。如果沒有__contains__就嘗試用__iter__逐個(gè)遍歷比對(duì)。如果__iter__也沒有就退回__getitem__從下標(biāo) 0 開始逐個(gè)取直到IndexError。這個(gè)優(yōu)先級(jí)設(shè)計(jì)很符合“最精確的方法最優(yōu)先”的原則。你在設(shè)計(jì)容器類時(shí)如果成員判斷能被一個(gè) O(1) 的集合計(jì)算完成那一定要實(shí)現(xiàn)__contains__否則默認(rèn)的遍歷方式可能要 O(n)。這個(gè)優(yōu)化在數(shù)據(jù)量大時(shí)非常明顯。4.5 一張表看清常用魔術(shù)方法的使用時(shí)機(jī)你寫的代碼解釋器實(shí)際調(diào)用備注obj othertype(obj).__add__(obj, other)左邊不行會(huì)嘗試other.__radd__obj * ntype(obj).__mul__(obj, n)類似的還有__rmul__len(obj)type(obj).__len__(obj)返回必須是非負(fù)整數(shù)obj[i]type(obj).__getitem__(obj, i)i 可以是 int、slice、str 等obj[i] vtype(obj).__setitem__(obj, i, v)賦值表達(dá)式for i in objtype(obj).__iter__(obj)沒有__iter__時(shí)退回__getitem__x in objtype(obj).__contains__(obj, x)沒有__contains__時(shí)退回迭代with obj as v:type(obj).__enter__(obj)/type(obj).__exit__(...)__exit__接收異常參數(shù)str(obj)/print(obj)type(obj).__str__(obj)沒有__str__時(shí)退回__repr__repr(obj)type(obj).__repr__(obj)調(diào)試器、交互式終端調(diào)用bool(obj)type(obj).__bool__(obj)沒有__bool__時(shí)退回__len__obj()type(obj).__call__(obj)讓實(shí)例可調(diào)用hash(obj)type(obj).__hash__(obj)與__eq__必須同步實(shí)現(xiàn)a btype(a).__eq__(a, b)也可觸發(fā)type(b).__eq__(b, a)5. 實(shí)戰(zhàn)排查與性能調(diào)優(yōu)中的幾個(gè)觀察視角5.1 用“打印大法”觀察魔術(shù)方法的真實(shí)調(diào)用時(shí)機(jī)魔術(shù)方法最大的特點(diǎn)是“隱式調(diào)用”。你在代碼里寫下一個(gè)并不能直接看到__add__被調(diào)用。排查問題時(shí)我經(jīng)常會(huì)在方法內(nèi)部臨時(shí)加一行print觀察它的觸發(fā)軌跡。class DebugList: def __init__(self, items): self.items list(items) def __len__(self): print(__len__ called) return len(self.items) def __getitem__(self, idx): print(f__getitem__ called: {idx}) return self.items[idx] dl DebugList([1, 2, 3]) print(len(dl)) # __len__ called for i in dl: # 會(huì)連續(xù)打印 __getitem__ called: 0 / 1 / 2 / 3 pass注意最后這個(gè)for循環(huán)會(huì)打印__getitem__ called: 0、1、2、3。第 3 次是 Python 在嘗試通過越界IndexError判斷“迭代結(jié)束”?？吹竭@你就能明白Python 的舊版序列迭代協(xié)議確實(shí)是這么工作的。如果不想給每個(gè)方法都加打印還有一個(gè)偷懶技巧在__getattribute__里臨時(shí)加一行print(name)能看到實(shí)例上所有屬性訪問的完整軌跡。但這個(gè)方法日志量極其龐大而且容易刷屏一般只在排查遞歸問題時(shí)才用。5.2__slots__不是魔術(shù)方法卻是性能問題的常見解藥嚴(yán)格來(lái)說__slots__是在類定義時(shí)聲明的一個(gè)類屬性它不是雙下劃線開頭的“協(xié)議方法”但它對(duì)理解對(duì)象屬性機(jī)制非常有幫助所以放在這里一起說。默認(rèn)情況下Python 的每個(gè)實(shí)例都有一個(gè)__dict__字典用來(lái)存放實(shí)例屬性。這個(gè)字典帶來(lái)了靈活的屬性增刪能力但也帶來(lái)了內(nèi)存開銷。如果一個(gè)類你會(huì)創(chuàng)建成千上萬(wàn)個(gè)實(shí)例并且字段是固定的可以用__slots__禁用這個(gè)字典class Point: __slots__ (x, y) def __init__(self, x, y): self.x x self.y y加上之后實(shí)例不再有__dict__屬性訪問在底層變成了類似 C 結(jié)構(gòu)體成員的固定偏移量訪問內(nèi)存占用大幅下降屬性訪問速度也會(huì)快一些。代價(jià)是不能隨意給實(shí)例添加新屬性。當(dāng)你發(fā)現(xiàn)程序內(nèi)存占用異常時(shí)優(yōu)先檢查有沒有大量對(duì)象都在維護(hù)著自己的__dict__。5.3 魔術(shù)方法查找走的不是實(shí)例字典一個(gè)非常隱蔽的坑是魔術(shù)方法的查找發(fā)生在類型類上而不是實(shí)例上。這意味著如果你這樣寫class A: pass a A() a.__len__ lambda: 42 len(a) # TypeError: object of type A has no len()這個(gè)len(a)依然會(huì)拋異常因?yàn)閘en()在type(a)即A類上找__len__而實(shí)例上的__len__屬性不影響類的協(xié)議查詢。理解這一點(diǎn)對(duì)調(diào)試非常有幫助。有些庫(kù)允許用戶為單個(gè)實(shí)例動(dòng)態(tài)掛載方法看起來(lái)“像”實(shí)現(xiàn)了協(xié)議但實(shí)際上只要不是定義在類上的內(nèi)置函數(shù)一律不認(rèn)。5.4 常見報(bào)錯(cuò)的快速定位我整理幾個(gè)最常見的異常和它們的真實(shí)原因排查時(shí)可以先對(duì)照一下報(bào)錯(cuò)信息真實(shí)原因TypeError: object of type X has no len()類沒有實(shí)現(xiàn)__len__或者手誤寫成了__length__之類的TypeError: X object is not iterable類沒有實(shí)現(xiàn)__iter__和__getitem__for無(wú)路可走TypeError: X object is not subscriptable類沒有實(shí)現(xiàn)__getitem__卻用了obj[i]TypeError: X object does not support item assignment類沒有實(shí)現(xiàn)__setitem__卻用了obj[i] vTypeError: X object is not callable類沒有實(shí)現(xiàn)__call__卻寫了obj()AttributeError: __enter__類沒有實(shí)現(xiàn)__enter__/__exit__卻用了with obj:TypeError: unhashable type: X類定義了__eq__但沒定義__hash__或者哈希字段是可變的RecursionError__getattr__/__getattribute__/__setattr__內(nèi)部又訪問了同名字段出現(xiàn)無(wú)限遞歸5.5 一個(gè)務(wù)實(shí)的開發(fā)習(xí)慣寫完類先補(bǔ)“協(xié)議三件套”在我自己寫類庫(kù)和接手別人代碼時(shí)很容易通過一個(gè)類有沒有補(bǔ)全基礎(chǔ)協(xié)議方法來(lái)判斷作者的工程經(jīng)驗(yàn)。所謂“協(xié)議三件套”就是__repr__、__eq__、__hash__。__repr__讓調(diào)試信息和日志輸出不再是一堆__main__.X object at 0x...直接能看到關(guān)鍵字段。__eq__讓對(duì)象之間的比較符合業(yè)務(wù)直覺而不是默認(rèn)比較內(nèi)存地址。__hash__讓對(duì)象能安全地放進(jìn)set、dict、frozenset配合__eq__一起用才不會(huì)被臨時(shí)報(bào)unhashable的錯(cuò)卡住。這三個(gè)方法補(bǔ)完之后你的類才真正具備“值對(duì)象”的資格。尤其在寫數(shù)據(jù)模型、領(lǐng)域?qū)ο?、配置?xiàng)這類場(chǎng)景時(shí)這套組合帶來(lái)的提升是立竿見影的。我個(gè)人在實(shí)際調(diào)試中還有一個(gè)體會(huì)如果某天你發(fā)現(xiàn)一個(gè)自定義對(duì)象在set里出現(xiàn)了“重復(fù)元素”或者dict的 key 明明看起來(lái)一樣卻查不到先別懷疑是哈希算法的問題第一反應(yīng)應(yīng)該是去看這個(gè)類的__eq__和__hash__是否共同實(shí)現(xiàn)了、它們依賴的字段是不是可變對(duì)象。這類問題往往藏得很深因?yàn)楸砻鎴?bào)錯(cuò)并不直接指向魔術(shù)方法。掌握雙下劃線這套協(xié)議之后你會(huì)發(fā)現(xiàn)自己寫的類能和內(nèi)置類型一樣順手排錯(cuò)速度也會(huì)快一個(gè)檔次。