您好,登錄后才能下訂單哦!
這篇文章主要為大家展示了“Python容器怎么用”,內容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領大家一起研究并學習一下“Python容器怎么用”這篇文章吧。
Python容器使用的5個技巧和2個誤區
“容器”這兩個字很少被 Python 技術文章提起。一看到“容器”,大家想到的多是那頭藍色小鯨魚:Docker,但這篇文章和它沒有任何關系。本文里的容器,是 Python 中的一個抽象概念,是對專門用來裝其他對象的數據類型的統稱。
在 Python 中,有四類最常見的內建容器類型: 列表(list)、 元組(tuple)、 字典(dict)、 集合(set)。通過單獨或是組合使用它們,可以高效的完成很多事情。
Python 語言自身的內部實現細節也與這些容器類型息息相關。比如 Python 的類實例屬性、全局變量 globals() 等就都是通過字典類型來存儲的。
在這篇文章里,我首先會從容器類型的定義出發,嘗試總結出一些日常編碼的最佳實踐。之后再圍繞各個容器類型提供的特殊機能,分享一些編程的小技巧。
當我們談論容器時,我們在談些什么?
我在前面給了“容器”一個簡單的定義:專門用來裝其他對象的就是容器。但這個定義太寬泛了,無法對我們的日常編程產生什么指導價值。要真正掌握 Python 里的容器,需要分別從兩個層面入手:
·底層實現:內置容器類型使用了什么數據結構?某項操作如何工作?
·高層抽象:什么決定了某個對象是不是容器?哪些行為定義了容器?
下面,讓我們一起站在這兩個不同的層面上,重新認識容器。
底層看容器
Python 是一門高級編程語言,它所提供的內置容器類型,都是經過高度封裝和抽象后的結果。和“鏈表”、“紅黑樹”、“哈希表”這些名字相比,所有 Python 內建類型的名字,都只描述了這個類型的功能特點,其他人完全沒法只通過這些名字了解它們的哪怕一丁點內部細節。
這是 Python 編程語言的優勢之一。相比 C 語言這類更接近計算機底層的編程語言,Python 重新設計并實現了對編程者更友好的內置容器類型,屏蔽掉了內存管理等額外工作。為我們提供了更好的開發體驗。
但如果這是 Python 語言的優勢的話,為什么我們還要費勁去了解容器類型的實現細節呢?答案是:關注細節可以幫助我們編寫出更快的代碼。
寫更快的代碼
1. 避免頻繁擴充列表/創建新列表
所有的內建容器類型都不限制容量。如果你愿意,你可以把遞增的數字不斷塞進一個空列表,最終撐爆整臺機器的內存。
在 Python 語言的實現細節里,列表的內存是按需分配的[注1],當某個列表當前擁有的內存不夠時,便會觸發內存擴容邏輯。而分配內存是一項昂貴的操作。雖然大部分情況下,它不會對你的程序性能產生什么嚴重的影響。但是當你處理的數據量特別大時,很容易因為內存分配拖累整個程序的性能。
還好,Python 早就意識到了這個問題,并提供了官方的問題解決指引,那就是:“變懶”。
如何解釋“變懶”? range() 函數的進化是一個非常好的例子。
在 Python 2 中,如果你調用 range(100000000),需要等待好幾秒才能拿到結果,因為它需要返回一個巨大的列表,花費了非常多的時間在內存分配與計算上。但在 Python 3 中,同樣的調用馬上就能拿到結果。因為函數返回的不再是列表,而是一個類型為 range 的懶惰對象,只有在你迭代它、或是對它進行切片時,它才會返回真正的數字給你。
所以說,為了提高性能,內建函數 range “變懶”了。而為了避免過于頻繁的內存分配,在日常編碼中,我們的函數同樣也需要變懶,這包括:
·更多的使用 yield 關鍵字,返回生成器對象
·盡量使用生成器表達式替代列表推導表達式
·生成器表達式: (iforinrange(100))
·列表推導表達式: [iforinrange(100)]
·盡量使用模塊提供的懶惰對象:
·使用 re.finditer 替代 re.findall
·直接使用可迭代的文件對象: forlineinfp,而不是 forlineinfp.readlines()
2. 在列表頭部操作多的場景使用 deque 模塊
列表是基于數組結構(Array)實現的,當你在列表的頭部插入新成員( list.insert(0,item))時,它后面的所有其他成員都需要被移動,操作的時間復雜度是 O(n)。這導致在列表的頭部插入成員遠比在尾部追加( list.append(item) 時間復雜度為 O(1))要慢。
如果你的代碼需要執行很多次這類操作,請考慮使用 collections.deque 類型來替代列表。因為 deque 是基于雙端隊列實現的,無論是在頭部還是尾部追加元素,時間復雜度都是 O(1)。
3. 使用集合/字典來判斷成員是否存在
當你需要判斷成員是否存在于某個容器時,用集合比列表更合適。因為 itemin[...] 操作的時間復雜度是 O(n),而 itemin{...} 的時間復雜度是 O(1)。這是因為字典與集合都是基于哈希表(Hash Table)數據結構實現的。
# 這個例子不是特別恰當,因為當目標集合特別小時,使用集合還是列表對效率的影響微乎其微 # 但這不是重點 :) VALID_NAMES = ["piglei", "raymond", "bojack", "caroline"] # 轉換為集合類型專門用于成員判斷 VALID_NAMES_SET = set(VALID_NAMES) def validate_name(name): if name not in VALID_NAMES_SET: # 此處使用了 Python 3.6 添加的 f-strings 特性 raise ValueError(f"{name} is not a valid name!")
Hint: 強烈建議閱讀 TimeComplexity - Python Wiki,了解更多關于常見容器類型的時間復雜度相關內容。
如果你對字典的實現細節感興趣,也強烈建議觀看 Raymond Hettinger 的演講 Modern Dictionaries(YouTube)
高層看容器
Python 是一門“鴨子類型”語言:“當看到一只鳥走起來像鴨子、游泳起來像鴨子、叫起來也像鴨子,那么這只鳥就可以被稱為鴨子。”所以,當我們說某個對象是什么類型時,在根本上其實指的是:這個對象滿足了該類型的特定接口規范,可以被當成這個類型來使用。而對于所有內置容器類型來說,同樣如此。
打開位于 collections 模塊下的 abc(“抽象類 Abstract Base Classes”的首字母縮寫)子模塊,可以找到所有與容器相關的接口(抽象類)[注2]定義。讓我們分別看看那些內建容器類型都滿足了什么接口:
·列表(list):滿足 Iterable、 Sequence、 MutableSequence 等接口
·元組(tuple):滿足 Iterable、 Sequence
·字典(dict):滿足 Iterable、 Mapping、 MutableMapping [注3]
·集合(set):滿足 Iterable、 Set、 MutableSet [注4]
每個內置容器類型,其實就是滿足了多個接口定義的組合實體。比如所有的容器類型都滿足 “可被迭代的”(Iterable) 這個接口,這意味著它們都是“可被迭代”的。但是反過來,不是所有“可被迭代”的對象都是容器。就像字符串雖然可以被迭代,但我們通常不會把它當做“容器”來看待。
了解這個事實后,我們將在 Python 里重新認識面向對象編程中最重要的原則之一:面向接口而非具體實現來編程。
讓我們通過一個例子,看看如何理解 Python 里的“面向接口編程”。
寫擴展性更好的代碼
某日,我們接到一個需求:有一個列表,里面裝著很多用戶評論,為了在頁面正常展示,需要將所有超過一定長度的評論用省略號替代。
這個需求很好做,很快我們就寫出了第一個版本的代碼:
# 注:為了加強示例代碼的說明性,本文中的部分代碼片段使用了Python 3.5 # 版本添加的 Type Hinting 特性 def add_ellipsis(comments: typing.List[str], max_length: int = 12): """如果評論列表里的內容超過 max_length,剩下的字符用省略號代替 """ index = 0 for comment in comments: comment = comment.strip() if len(comment) > max_length: comments[index] = comment[:max_length] + '...' index += 1 return comments comments = [ "Implementation note", "Changed", "ABC for generator", ] print("\n".join(add_ellipsis(comments))) # OUTPUT: # Implementati... # Changed # ABC for gene...
上面的代碼里, add_ellipsis 函數接收一個列表作為參數,然后遍歷它,替換掉需要修改的成員。這一切看上去很合理,因為我們接到的最原始需求就是:“有一個 列表,里面...”。但如果有一天,我們拿到的評論不再是被繼續裝在列表里,而是在不可變的元組里呢?
那樣的話,現有的函數設計就會逼迫我們寫出 add_ellipsis(list(comments)) 這種即慢又難看的代碼了。
面向容器接口編程
我們需要改進函數來避免這個問題。因為 add_ellipsis 函數強依賴了列表類型,所以當參數類型變為元組時,現在的函數就不再適用了(原因:給 comments[index] 賦值的地方會拋出 TypeError 異常)。如何改善這部分的設計?秘訣就是:讓函數依賴“可迭代對象”這個抽象概念,而非實體列表類型。
使用生成器特性,函數可以被改成這樣:
def add_ellipsis_gen(comments: typing.Iterable[str], max_length: int = 12): """如果可迭代評論里的內容超過 max_length,剩下的字符用省略號代替 """ for comment in comments: comment = comment.strip() if len(comment) > max_length: yield comment[:max_length] + '...' else: yield comment print("\n".join(add_ellipsis_gen(comments)))
在新函數里,我們將依賴的參數類型從列表改成了可迭代的抽象類。這樣做有很多好處,一個最明顯的就是:無論評論是來自列表、元組或是某個文件,新函數都可以輕松滿足
# 處理放在元組里的評論 comments = ("Implementation note", "Changed", "ABC for generator") print("\n".join(add_ellipsis_gen(comments))) # 處理放在文件里的評論 with open("comments") as fp: for comment in add_ellipsis_gen(fp): print(comment)
將依賴由某個具體的容器類型改為抽象接口后,函數的適用面變得更廣了。除此之外,新函數在執行效率等方面也都更有優勢。現在讓我們再回到之前的問題。從高層來看,什么定義了容器?
答案是:各個容器類型實現的接口協議定義了容器。不同的容器類型在我們的眼里,應該是 是否可以迭代、 是否可以修改、 有沒有長度 等各種特性的組合。我們需要在編寫相關代碼時,更多的關注容器的抽象屬性,而非容器類型本身,這樣可以幫助我們寫出更優雅、擴展性更好的代碼。
Hint:在 itertools 內置模塊里可以找到更多關于處理可迭代對象的寶藏。
常用技巧
1. 使用元組改善分支代碼
有時,我們的代碼里會出現超過三個分支的 if/else 。就像下面這樣:
import time def from_now(ts): """接收一個過去的時間戳,返回距離當前時間的相對時間文字描述 """ now = time.time() seconds_delta = int(now - ts) if seconds_delta < 1: return "less than 1 second ago" elif seconds_delta < 60: return "{} seconds ago".format(seconds_delta) elif seconds_delta < 3600: return "{} minutes ago".format(seconds_delta // 60) elif seconds_delta < 3600 * 24: return "{} hours ago".format(seconds_delta // 3600) else: return "{} days ago".format(seconds_delta // (3600 * 24)) now = time.time() print(from_now(now)) print(from_now(now - 24)) print(from_now(now - 600)) print(from_now(now - 7500)) print(from_now(now - 87500)) # OUTPUT: # less than 1 second ago # 24 seconds ago # 10 minutes ago # 2 hours ago # 1 days ago
上面這個函數挑不出太多毛病,很多很多人都會寫出類似的代碼。但是,如果你仔細觀察它,可以在分支代碼部分找到一些明顯的“邊界”。比如,當函數判斷某個時間是否應該用“秒數”展示時,用到了 60。而判斷是否應該用分鐘時,用到了 3600。
從邊界提煉規律是優化這段代碼的關鍵。如果我們將所有的這些邊界放在一個有序元組中,然后配合二分查找模塊 bisect。整個函數的控制流就能被大大簡化:
import bisect # BREAKPOINTS 必須是已經排好序的,不然無法進行二分查找 BREAKPOINTS = (1, 60, 3600, 3600 * 24) TMPLS = ( # unit, template (1, "less than 1 second ago"), (1, "{units} seconds ago"), (60, "{units} minutes ago"), (3600, "{units} hours ago"), (3600 * 24, "{units} days ago"), ) def from_now(ts): """接收一個過去的時間戳,返回距離當前時間的相對時間文字描述 """ seconds_delta = int(time.time() - ts) unit, tmpl = TMPLS[bisect.bisect(BREAKPOINTS, seconds_delta)] return tmpl.format(units=seconds_delta // unit)
除了用元組可以優化過多的 if/else 分支外,有些情況下字典也能被用來做同樣的事情。關鍵在于從現有代碼找到重復的邏輯與規律,并多多嘗試。
2. 在更多地方使用動態解包
動態解包操作是指使用 * 或 ** 運算符將可迭代對象“解開”的行為,在 Python 2 時代,這個操作只能被用在函數參數部分,并且對出現順序和數量都有非常嚴格的要求,使用場景非常單一。
def calc(a, b, multiplier=1): return (a + b) * multiplier # Python2 中只支持在函數參數部分進行動態解包 print calc(*[1, 2], **{"multiplier": 10}) # OUTPUT: 30
不過,Python 3 尤其是 3.5 版本后, * 和 ** 的使用場景被大大擴充了。舉個例子,在 Python 2 中,如果我們需要合并兩個字典,需要這么做:
def merge_dict(d1, d2): # 因為字典是可被修改的對象,為了避免修改原對象,此處需要復制一個 d1 的淺拷貝 result = d1.copy() result.update(d2) return result user = merge_dict({"name": "piglei"}, {"movies": ["Fight Club"]})
但是在 Python 3.5 以后的版本,你可以直接用 ** 運算符來快速完成字典的合并操作:
user = {**{"name": "piglei"}, **{"movies": ["Fight Club"]}}
除此之外,你還可以在普通賦值語句中使用 * 運算符來動態的解包可迭代對象。如果你想詳細了解相關內容,可以閱讀下面推薦的 PEP。
Hint:推進動態解包場景擴充的兩個 PEP:
·PEP 3132 -- Extended Iterable Unpacking | Python.org
·PEP 448 -- Additional Unpacking Generalizations | Python.org
3. 最好不用“獲取許可”,也無需“要求原諒”
這個小標題可能會稍微讓人有點懵,讓我來簡短的解釋一下:“獲取許可”與“要求原諒”是兩種不同的編程風格。如果用一個經典的需求:“計算列表內各個元素出現的次數” 來作為例子,兩種不同風格的代碼會是這樣:
# AF: Ask for Forgiveness # 要做就做,如果拋出異常了,再處理異常 def counter_af(l): result = {} for key in l: try: result[key] += 1 except KeyError: result[key] = 1 return result # AP: Ask for Permission # 做之前,先問問能不能做,可以做再做 def counter_ap(l): result = {} for key in l: if key in result: result[key] += 1 else: result[key] = 1 return result
整個 Python 社區對第一種 Ask for Forgiveness 的異常捕獲式編程風格有著明顯的偏愛。這其中有很多原因,首先,在 Python 中拋出異常是一個很輕量的操作。其次,第一種做法在性能上也要優于第二種,因為它不用在每次循環的時候都做一次額外的成員檢查。
不過,示例里的兩段代碼在現實世界中都非常少見。為什么?因為如果你想統計次數的話,直接用 collections.defaultdict 就可以了:
from collections import defaultdict def counter_by_collections(l): result = defaultdict(int) for key in l: result[key] += 1 return result
這樣的代碼既不用“獲取許可”,也無需“請求原諒”。整個代碼的控制流變得更清晰自然了。所以,如果可能的話,請盡量想辦法省略掉那些非核心的異常捕獲邏輯。一些小提示:
·操作字典成員時:使用 collections.defaultdict 類型
·或者使用 dict[key]=dict.setdefault(key,0)+1 內建函數
·如果移除字典成員,不關心是否存在:
·調用 pop 函數時設置默認值,比如 dict.pop(key,None)
·在字典獲取成員時指定默認值: dict.get(key,default_value)
·對列表進行不存在的切片訪問不會拋出 IndexError 異常: ["foo"][100:200]
4. 使用 next() 函數
next() 是一個非常實用的內建函數,它接收一個迭代器作為參數,然后返回該迭代器的下一個元素。使用它配合生成器表達式,可以高效的實現“從列表中查找第一個滿足條件的成員”之類的需求。
numbers = [3, 7, 8, 2, 21] # 獲取并 **立即返回** 列表里的第一個偶數 print(next(i for i in numbers if i % 2 == 0)) # OUTPUT: 8
5. 使用有序字典來去重
字典和集合的結構特點保證了它們的成員不會重復,所以它們經常被用來去重。但是,使用它們倆去重后的結果會丟失原有列表的順序。這是由底層數據結構“哈希表(Hash Table)”的特點決定的。
>>> l = [10, 2, 3, 21, 10, 3] # 去重但是丟失了順序 >>> set(l) {3, 10, 2, 21}
如果既需要去重又必須保留順序怎么辦?我們可以使用 collections.OrderedDict 模塊:
Hint: 在 Python 3.6 中,默認的字典類型修改了實現方式,已經變成有序的了。并且在 Python 3.7 中,該功能已經從 語言的實現細節 變成了為 可依賴的正式語言特性。
但是我覺得讓整個 Python 社區習慣這一點還需要一些時間,畢竟目前“字典是無序的”還是被印在無數本 Python 書上。所以,我仍然建議在一切需要有序字典的地方使用 OrderedDict。
常見誤區
1. 當心那些已經枯竭的迭代器
在文章前面,我們提到了使用“懶惰”生成器的種種好處。但是,所有事物都有它的兩面性。生成器的最大的缺點之一就是:它會枯竭。當你完整遍歷過它們后,之后的重復遍歷就不能拿到任何新內容了。
numbers = [1, 2, 3] numbers = (i * 2 for i in numbers) # 第一次循環會輸出 2, 4, 6 for number in numbers: print(number) # 這次循環什么都不會輸出,因為迭代器已經枯竭了 for number in numbers: print(number)
而且不光是生成器表達式,Python 3 里的 map、filter 內建函數也都有一樣的特點。忽視這個特點很容易導致代碼中出現一些難以察覺的 Bug。
Instagram 就在項目從 Python 2 到 Python 3 的遷移過程中碰到了這個問題。它們在 PyCon 2017 上分享了對付這個問題的故事。訪問文章 Instagram 在 PyCon 2017 的演講摘要,搜索“迭代器”可以查看詳細內容。
2. 別在循環體內修改被迭代對象
這是一個很多 Python 初學者會犯的錯誤。比如,我們需要一個函數來刪掉列表里的所有偶數:
def remove_even(numbers): """去掉列表里所有的偶數 """ for i, number in enumerate(numbers): if number % 2 == 0: # 有問題的代碼 del numbers[i] numbers = [1, 2, 7, 4, 8, 11] remove_even(numbers) print(numbers) # OUTPUT: [1, 7, 8, 11]
注意到結果里那個多出來的“8”了嗎?當你在遍歷一個列表的同時修改它,就會出現這樣的事情。因為被迭代的對象numbers在循環過程中被修改了。遍歷的下標在不斷增長,而列表本身的長度同時又在不斷縮減。這樣就會導致列表里的一些成員其實根本就沒有被遍歷到。
所以對于這類操作,請使用一個新的空列表保存結果,或者利用 yield 返回一個生成器。而不是修改被迭代的列表或是字典對象本身。
以上是“Python容器怎么用”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。