流暢的Python 第二章：豐富的序列
摘要：在日常Python開發中，我們頻繁與各種數據結構打交道，其中序列類型（如列表、元組、字符串）是基石。然而，你是否曾因對它們理解不深，而在性能優化、代碼可讀性或避免潛在陷阱上遇到瓶頸？本文將帶你深入探索Python序列的奧秘，從其設計哲學、高效構建方式，到高級操作技巧和適用場景，旨在幫助你避開常見“坑點”，寫出更健壯、更高效的Python代碼。
前言
你是否曾有過這樣的經歷：面對一份需要處理的數據，下意識地就用 list 來存儲，然后用 for 循環和 if 判斷來篩選轉換？或者，在調試一個看似簡單的程序時，卻發現數據行為異常，最終定位到是 list 和 tuple 的“不可變性”理解偏差？在Python的世界里，序列類型無處不在，它們是構建復雜數據邏輯的基石。然而，僅僅停留在“能用”的層面，往往會讓我們錯過許多提升代碼質量和運行效率的機會。
Python的設計哲學中，對序列的重視由來已久。早在Python誕生之前，Guido van Rossum 在ABC語言中的經驗，就為Python奠定了對序列“一視同仁”、內置豐富類型的基礎。這種對用戶友好的設計，使得Python在處理數據時顯得格外靈活。但正是這種靈活性，也要求我們更深入地理解不同序列類型的特性、適用場景以及它們背后的機制。本文將帶你跳出舒適區，深入剖析Python序列的方方面面，助你寫出更“Pythonic”且高效的代碼。
1. Python序列的演進與分類：理解基石
Python的序列類型是其強大數據處理能力的核心。我們可以從不同的維度來理解它們：
1.1 容器序列與扁平序列：存儲方式的差異
在Python中，序列可以大致分為兩類：
- 容器序列：如
list、tuple和collections.deque。它們可以存放不同類型的項，甚至可以嵌套其他容器。容器序列內部存儲的是所包含對象的引用。這意味著，一個列表可以同時包含整數、字符串、甚至另一個列表。 - 扁平序列：如
str、bytes和array.array。它們只能存放一種簡單類型的項。扁平序列在自己的內存空間中存儲所含內容的值，而不是各自不同的Python對象引用。例如，一個str對象直接存儲字符的編碼值，而不是每個字符的獨立對象。
這種差異決定了它們在內存使用和性能上的表現。容器序列由于存儲引用，每個被引用的Python對象在內存中都有一個包含元數據的標頭（例如 ob_refcnt 引用計數、ob_type 類型指針等），這使得它們在存儲大量小對象時會有額外的內存開銷。而扁平序列則更為緊湊，因為它們直接存儲值。
1.2 可變序列與不可變序列：行為模式的關鍵
你的數據是“活的”還是“死的”？這取決于序列的可變性。
- 可變序列：例如
list、bytearray、array.array和collections.deque。它們像一塊可以隨意涂抹的白板，你可以隨時增刪改內容。 - 不可變序列：例如
tuple、str和bytes。它們則像一張打印好的紙，內容固定，任何“修改”都會產生一張全新的紙。
值得注意的是：可變序列功能更強大，但這也帶來了風險。一個常見的陷阱是關于元組的“偽不變性”。元組的不可變性是“淺層”的——它保證的是其內部的引用不會變。如果元組里存了一個列表，雖然你不能把這個列表換掉，但你完全可以修改這個列表里的內容。
生產環境中需注意：優先使用不可變序列（如 tuple）來表示不應被修改的數據，這不僅能提升代碼的健壯性，還能讓你的數據成為字典的鍵或集合的元素，解鎖更多數據結構的可能性。
2. 列表推導式與生成器表達式：高效構建序列的利器
你是否曾為寫一個簡單的循環來過濾和轉換數據而感到繁瑣？
在Python中，構建序列的方式多種多樣，但列表推導式（List Comprehension）和生成器表達式（Generator Expression）無疑是其中最強大、最“Pythonic”的兩種。它們不僅能讓你告別冗長的 for 循環，還能讓代碼既優雅又高效。
2.1 告別繁瑣循環：列表推導式的優雅
列表推導式提供了一種簡潔的方式來創建列表，它通過對一個可迭代對象進行篩選和轉換來構建新列表。
場景：假設你有一個數字列表，現在想篩選出其中的偶數，并對每個偶數進行平方。
傳統寫法：
numbers = [1, 2, 3, 4, 5, 6]
even_squares = []
for num in numbers:if num % 2 == 0:even_squares.append(num * num)
print(even_squares)
# 輸出: [4, 16, 36]
列表推導式寫法：
numbers = [1, 2, 3, 4, 5, 6]
even_squares = [num * num for num in numbers if num % 2 == 0]
print(even_squares)
# 輸出: [4, 16, 36]
我們可以發現，列表推導式將循環、條件判斷和元素轉換整合到一行代碼中，極大地提高了代碼的可讀性和簡潔性。它比 map 和 filter 的組合更易于理解，因為所有邏輯都集中在一個地方。
經驗提示：
- 避免過度嵌套：雖然列表推導式支持多重
for和if，但當嵌套超過兩層時，代碼會迅速變得難以理解。記住，“可讀性優先”，此時應果斷回歸傳統循環。 - 理解變量泄露：在Python 2中，推導式內的變量會“泄露”到外層作用域，這是一個常見的陷阱。幸運的是，Python 3修復了此問題，其作用域已嚴格限定在推導式內部。
- 謹慎使用
:=：海象運算符雖強大，但在推導式中使用可能降低可讀性。除非確實需要復用計算結果，否則盡量避免，以免給團隊成員留下“謎題”。
2.2 內存效率的守護者：生成器表達式
雖然列表推導式非常方便，但它會一次性構建整個列表并存儲在內存中。對于處理大量數據或無限序列的場景，這可能會導致內存溢出。這時，生成器表達式就派上用場了。
生成器表達式的句法與列表推導式幾乎一樣，只不過將方括號 [] 換成了圓括號 ()。
場景：計算一個非常大的數字序列中所有偶數的平方和。
列表推導式（可能導致內存問題）：
# 假設 numbers 是一個非常大的列表
# even_squares = [num * num for num in numbers if num % 2 == 0]
# total_sum = sum(even_squares)
生成器表達式（內存高效）：
numbers = range(1, 10000000) # 模擬一個非常大的序列
total_sum = sum(num * num for num in numbers if num % 2 == 0)
print(total_sum)
# 生成器表達式不會一次性創建所有元素，而是按需逐個生成，極大地節省內存。
生成器表達式使用迭代器協議逐個產出項，而不是一次性構建整個列表。這就像流水線作業，只在需要時才生產下一個產品，極大地節省了內存空間。這種“按需加載”的特性，讓它成為處理大文件、網絡流或無限序列的理想選擇。
特別說明：
- 何時使用生成器：當你面對海量數據（如日志文件分析）、或需要實現惰性求值（lazy evaluation）時，生成器表達式是你的首選。它能將內存占用從GB級降到KB級。
- 警惕單次消費：生成器只能被遍歷一次。如果你需要多次使用結果，要么重新創建生成器，要么將其結果轉為列表——但這會失去內存優勢，需權衡利弊。
- 構建笛卡兒積：無論是列表還是生成器推導式，都能優雅地處理多層嵌套。例如，
[(x, y) for x in 'ABC' for y in '123']能清晰地表達出所有組合，比嵌套循環直觀得多。
3. 元組：不僅僅是不可變列表
許多Python初學者會將元組（tuple）簡單地理解為“不可變的列表”。雖然這在一定程度上是正確的，但它遠未概括元組的全部特性和用途。元組在Python中扮演著雙重角色。
3.1 元組的雙重身份：不可變列表與無字段名記錄
除了作為不可變列表使用外，元組更重要的一個作用是作為沒有字段名稱的記錄。
場景：存儲一個點的坐標信息。
作為不可變列表：
point_coords = (10, 20)
# 此時，我們關注的是 (10, 20) 這個序列本身，其內部元素不可變。
作為無字段名記錄：
# 假設我們知道第一個元素是緯度，第二個是經度
city_location = (34.0522, -118.2437) # (latitude, longitude)
name, lat, lon = ("Los Angeles", 34.0522, -118.2437)
# 此時，元組的項數通常是固定的，項的位置決定了數據的意義。
# 我們通過位置來訪問數據，而不是通過名稱。
當元組用作記錄時，其元素的順序和數量變得至關重要。例如，一個表示地理位置的元組，第一個元素通常是緯度，第二個是經度。這種用法在函數返回多個值時尤為常見。
實踐建議：
- 虛擬變量
_：在解包元組時，如果某個位置的元素你不需要，可以使用_作為虛擬變量來占位，例如name, _, _, (lat, lon) = record。 - 避免不必要的類：如果只是為了給幾個字段指定名稱，而不需要復雜的方法或繼承，使用元組作為記錄通常比創建一個簡單的類更輕量。
3.2 元組的“不可變性”與哈希性
元組的不可變性是一個常被誤解的點。正如前面提到的，元組的不可變性僅針對其內部存儲的引用。這意味著你不能刪除或替換元組中的引用。然而，如果元組中的某個元素本身是可變對象（如 list），那么這個可變對象的內容是可以被修改的。
my_tuple = (1, [2, 3], 4)
print(my_tuple) # (1, [2, 3], 4)my_tuple[1].append(5) # 修改元組中引用的列表
print(my_tuple) # (1, [2, 3, 5], 4)# 嘗試修改元組的引用會報錯
# my_tuple[0] = 10 # TypeError: 'tuple' object does not support item assignment
一個常見的誤區是：認為包含可變對象的元組仍然是可哈希的。Python中可哈希的對象必須滿足：內容不可變、哈希值在其生命周期內不變。因此，如果元組的元素包含可變對象（如列表），那么整個元組會因為元素的不可哈希性而變得不可哈希，從而不能作為字典的鍵或集合的元素。
3.3 元組的性能優勢
元組在某些場景下比列表具有性能優勢：
- 字節碼生成：Python編譯器在處理元組字面量時，可以一次性生成元組常量的字節碼，而列表則需要將每個元素作為獨立常量推入數據棧再構建。
- 復制行為：
tuple(t)對于已是元組的t會直接返回其引用，不涉及復制；而list(l)總是會創建列表l的副本。 - 內存分配：元組實例的長度固定，內存分配正好夠用；列表則會預留一些額外空間以備追加元素。
- 引用存儲：元組中項的引用直接存儲在元組結構體內部的數組中，而列表的引用數組指針存儲在別處。這在某些情況下可能帶來更好的CPU緩存效率。
我的經驗是：當數據集合固定不變，且需要作為字典鍵或集合元素時，元組是比列表更好的選擇。
4. 序列操作的藝術：拆包、模式匹配與切片
在Python的世界里，處理序列數據就像烹飪一道佳肴，既要講究食材（數據）的品質，更要注重技法（操作）的精妙。本節我們將深入探討Python序列操作的藝術，特別是拆包和模式匹配這兩大利器，它們能讓你的代碼更具可讀性、更少出錯，并且充滿Pythonic的優雅。
4.1 序列拆包：告別索引，像聊天一樣取數據f
還在用 list[0], list[1] 一個個地取值嗎？當函數返回多個值，或者你需要從數據結構中快速提取特定部分時，這種“按部就班”的方式是不是顯得有些笨拙？
別擔心，Python的**序列拆包（Unpacking）**正是為解決這個痛點而生！它允許你像日常對話一樣，直接將序列中的元素“分配”給多個變量，無需手動通過索引訪問，極大提升了代碼的可讀性和開發效率。
它如何工作？
想象一下，一個函數辛辛苦苦幫你查詢到了用戶的姓名、年齡和城市，并打包成一個元組返回：
def get_user_info():# 模擬從數據庫或其他源獲取用戶信息return ("Alice", 30, "New York")# 傳統方式可能需要：
# info = get_user_info()
# name = info[0]
# age = info[1]
# city = info[2]# 拆包的優雅姿勢：一行代碼搞定！
name, age, city = get_user_info()
print(f"姓名: {name}, 年齡: {age}, 城市: {city}")
# 輸出: 姓名: Alice, 年齡: 30, 城市: New York
你看，通過拆包，代碼變得像自然語言一樣流暢！值得注意的是，拆包的目標可以是任何可迭代對象，即便它不支持傳統的索引訪問（比如生成器），也能輕松應對。這不僅減少了潛在的索引越界錯誤，還讓代碼邏輯更加清晰。
進階實踐：讓拆包更靈活
-
星號拆包
*：收集剩余項的魔術手
當序列的長度不確定，或者你只關心開頭和結尾的少數幾個元素，而想把中間所有元素“打包”起來時，星號*就能派上大用場。它能幫你捕獲序列中剩余的項，并將它們收集到一個列表中。data_points = [10, 20, 30, 40, 50, 60] first_val, *middle_vals, last_val = data_points print(f"第一個值: {first_val}, 中間值集合: {middle_vals}, 最后一個值: {last_val}") # 輸出: 第一個值: 10, 中間值集合: [20, 30, 40, 50], 最后一個值: 60經驗提示：在一次拆包賦值中，只能對一個變量使用
*前綴，但它的位置可以非常靈活，無論在開頭、中間還是末尾，都能完美工作。 -
嵌套拆包：處理復雜結構的利器
如果你的數據結構本身是嵌套的，拆包也能層層深入，輕松應對。只要值的嵌套結構與你的拆包模式相匹配，Python就能像剝洋蔥一樣，幫你提取出深層的數據。
例如(a, b, (c, d))可以完美匹配[val1, val2, (nested_val1, nested_val2)]這樣的結構。
4.2 序列模式匹配：Python 3.10+ 的智能開關
當我們需要根據數據的結構和內容來執行不同的邏輯時，傳統的 if/elif/else 語句往往會變得冗長而難以維護，特別是當數據結構嵌套復雜時，代碼中充斥著大量的索引判斷和類型檢查。Python 3.10 引入的結構化模式匹配（Structural Pattern Matching），為我們帶來了處理復雜數據結構的全新“智能開關”，其中序列模式匹配更是其在數據解析方面的一大亮點。
（特別說明：這是一個 Python 3.10+ 的新特性，如果你還在使用舊版本，可能無法體驗到它的強大。強烈建議升級到最新Python版本，或參考官方文檔了解兼容性差異。）
為什么它如此重要？
設想一個場景：你正在處理不同格式的日志記錄，這些記錄可能以列表、元組等序列形式傳入，且格式各異，你需要根據其內部結構來執行不同的操作。過去，這會是一場 if-elif-else 的“嵌套地獄”。現在，match/case 語法讓一切變得聲明式、直觀：
def process_log_record(record):"""處理不同格式的日志記錄，演示序列模式匹配的用法。"""match record:# 匹配一個包含名稱、兩個占位符和一個經緯度元組的序列# 并且經度必須小于等于0case [name, _, _, (lat, lon)] if lon <= 0:print(f"[負經度告警] 地點: {name:<15} | 緯度: {lat:>9.4f} | 經度: {lon:>9.4f}")# 匹配一個命令和其后任意數量的參數case [command, *args]:print(f"[執行命令] 命令: '{command}', 參數: {args}")# 匹配空序列case []:print("[空記錄] 收到一個空序列。")# 兜底模式：處理所有不匹配上述模式的情況case _:print(f"[未知格式] 無法識別的記錄: {record}")process_log_record(["CityA", 1, 2, (30.0, -10.0)]) # 匹配第一個case
process_log_record(["run", "script.py", "--debug", "-v"]) # 匹配第二個case
process_log_record([]) # 匹配空序列
process_log_record("just a string") # 匹配兜底模式
process_log_record((1, 2, 3)) # 同樣會匹配，因為模式匹配中元組和列表等價
核心原則與實用技巧：
- 結構匹配：
match會嘗試將輸入對象（record）與case后面的模式進行結構性匹配。對于序列模式，它會檢查對象是否是序列，并且其內部結構（項的數量、嵌套結構）是否與模式吻合。 - 元組與列表無異：在序列模式匹配中，方括號
[]和圓括號()的含義是完全相同的，都表示匹配一個序列。這大大增加了匹配的靈活性，無需關心原始序列是列表還是元組。 - 衛語句
if：添加自定義條件
僅僅匹配結構可能還不夠，有時我們還需要根據值的內容進行更細致的判斷。這時，case后面的if衛語句就派上用場了！只有當模式匹配成功并且衛語句的條件為真時，對應的case代碼塊才會被執行。 _通配符：占位符的藝術
當你只關心序列中特定位置的某些項，而對其他位置的值不感興趣時，可以使用_作為通配符。它會匹配任何項，但不會將值綁定到任何變量，保持代碼的簡潔性。- 兜底
case _：健壯代碼的基石
生產環境中強烈建議提供一個case _作為兜底模式，它能捕獲所有未被明確匹配的情況，避免程序因為意料之外的輸入而“悄無聲息”地失敗，或者拋出未處理的異常，提升程序的健壯性。
一個值得注意的“陷阱”：
在 match/case 上下文中，str、bytes 和 bytearray 這三類常見的序列實例并不會被當作序列來匹配，而是被視為“原子”值進行整體匹配。這意味著 case [x, y]: 永遠不會匹配一個字符串。如果你的確需要將它們作為序列來解構匹配，你需要先進行顯式轉換，例如 case list(my_str_as_list):，這一點在處理混合類型數據時尤其重要，需要特別留意，避免不必要的問題。
4.3 切片：序列的靈活視圖
你在處理大量數據時，是否經常需要提取其中的“一段”？比如前100條記錄，或是每隔一行的數據？
這就是切片（Slicing）的用武之地。它就像一把精準的手術刀，能讓你從任何序列中優雅地取出所需的子序列，而無需復雜的循環。
生活化類比：想象你在看一本書，切片就像是用便簽紙標記你正在讀的章節范圍 [start:end)。你從第2頁（start）開始讀，到第5頁（end）之前停下，這意味著你讀了第2、3、4頁，共 5-2=3 頁。這正是Python切片 data[1:4] 的邏輯（索引從0開始）。
data = [10, 20, 30, 40, 50, 60]
subset = data[1:4] # 從索引1開始，到索引4之前（不包含4），就像便簽紙的范圍
print(subset) # 輸出: [20, 30, 40]
為什么是“前閉后開”？Python設計哲學的小秘密
初學者常常疑惑：為什么切片和range()函數一樣，都是排除最后一項？這并非偶然，而是Python設計者深思熟慮的約定，與從零開始的索引完美契合，并帶來了實實在在的好處：
- 長度一眼明了：
my_list[:3]的長度就是3，直觀易懂。 - 長度計算簡便：
stop - start，結果就是切片的長度，無需額外加減。 - 無縫拆分序列：
my_list[:x]和my_list[x:]兩個切片，可以在索引x處將序列完美地一分為二，既不重疊也不遺漏，這對于數據處理和算法實現來說極其方便。
切片的“花式”玩法：從入門到進階
-
步距
s[a:b:c]：除了起始和結束，切片還能玩出“跳躍”的花樣。第三個參數c允許你指定步距。比如，data[::2]能輕松獲取所有偶數索引的元素。更有趣的是，步距可以是負數，data[::-1]可是反轉序列的“神器”！ -
多維切片與省略號
...：雖然Python內置序列大多是一維的，但在處理像NumPy數組這樣的多維數據時，切片的威力會更上一層樓。[]運算符可以接受逗號分隔的多個索引或切片（例如a[i, j]）。而...（Ellipsis對象的別名）更是多維切片中的一個“魔法符”，它能代表“所有剩余的維度”，讓多維操作變得異常簡潔。
增量賦值：+= 和 *= 背后隱藏的真相
你平時用 += 或 *= 來更新列表或字符串時，有沒有想過Python在幕后做了什么？這些增量賦值運算符（如 +=、*=）對序列的行為，其實取決于序列是否實現了像 __iadd__ 這樣的“原地操作”方法。
- 可變序列（如
list）：如果序列實現了這些原地方法，它們會直接在原對象上進行修改，效率更高，就像你在原地“裝修”房子一樣。 - 不可變序列（如
tuple或str）：由于它們天生不可變，這些操作會創建一個全新的對象，然后將新值賦給原變量。這就像你不能“裝修”房子，只能“重建”一棟新房子，然后搬進去。
新手“踩坑”預警：當序列中出現“叛逆”的可變項
這里有一個經典的“陷阱”，幾乎每個Pythonista都可能不小心“踩”過：當序列中包含可變項時，a * n 這樣的表達式可能會導致意想不到的“集體行動”。
例如，你想要創建一個3x3的棋盤，每個格子都初始化為空：
weird_board = [['_'] * 3] * 3
print(weird_board)
# 看起來輸出很正常：
# [['_', '_', '_'], ['_', '_', '_'], ['_', '_', '_']]
但當你嘗試修改其中一個子列表時：
weird_board[1][2] = 'O' # 嘗試修改第二行第三列的元素
print(weird_board)
# 😱 結果讓你大跌眼鏡：
# [['_', '_', 'O'], ['_', '_', 'O'], ['_', '_', 'O']]
# 所有的子列表都被修改了！這是因為 `*` 運算符在這里執行的是“引用復制”，而不是值復制！
# 所有的子列表都指向了內存中的同一個對象！
我的看法：
在日常開發中，遇到這種“引用復制”的坑點，最穩妥的辦法是：
-
避免在不可變序列（如元組）中存放可變項：雖然Python允許，但這會讓你在調試時“追悔莫及”。
-
謹慎使用
*運算符復制包含可變對象的序列：如果你需要創建多個獨立的子列表，請務必使用列表推導式或深拷貝來確保每個子列表都是獨立的個體。比如，上述棋盤的正確創建方式應該是：correct_board = [['_'] * 3 for _ in range(3)] print(correct_board) # [['_', '_', '_'], ['_', '_', '_'], ['_', '_', '_']]correct_board[1][2] = 'O' print(correct_board) # [['_', '_', '_'], ['_', '_', 'O'], ['_', '_', '_']] # 這才是我們想要的結果！
記住，Python的簡潔強大伴隨著一些你必須了解的“潛規則”。理解這些機制，能讓你寫出更健壯、更符合預期的代碼。
5. 何時跳出列表的舒適區：選擇更合適的序列類型
你是不是也覺得list萬能？在小數據量時確實如此，但當數據規模上來后，性能瓶頸就出現了。
list 類型簡單靈活，是Python中最常用的序列。然而，在面對特定需求時，它并非總是最佳選擇。Python標準庫提供了多種專門優化的序列類型，理解并選擇它們能顯著提升代碼的性能和效率。
5.1 array.array：緊湊的同類型數值序列
當你需要處理大量同類型數值（如整數、浮點數）時，array.array 是一個比 list 更高效的選擇。
場景：存儲一百萬個浮點數。
import array
import sys# 使用列表存儲浮點數
list_of_floats = [float(i) for i in range(1000000)]
print(f"List size: {sys.getsizeof(list_of_floats)} bytes")
# 輸出: List size: 8000056 bytes (大致，具體取決于Python版本和系統)# 使用array.array存儲浮點數 ('d' 表示雙精度浮點數)
array_of_floats = array.array('d', (float(i) for i in range(1000000)))
print(f"Array size: {sys.getsizeof(array_of_floats)} bytes")
# 輸出: Array size: 8000064 bytes (大致，但內部存儲更緊湊)
array.array 像C語言數組一樣精簡，它存儲的不是完整的Python對象引用，而是表示相應機器值的壓縮字節。這就像把每個數字直接刻在金屬板上，而不是用紙條寫好再放進文件夾，自然更節省空間。
創建 array 對象時需要提供一個類型代碼（如 'b' 代表有符號字符，'d' 代表雙精度浮點數），這決定了底層C類型如何存儲數組中的各項。這既是優勢也是限制——Python不允許向 array 中添加與指定類型不同的值，確保了內存布局的緊湊性。
特別說明：當你處理科學計算或大規模數值數據時，雖然
array.array比list更高效，但通常numpy.ndarray是更好的選擇，它提供了更豐富的數學運算支持。
5.2 collections.deque：高效的雙端隊列
如果你的應用場景經常需要在序列的兩端進行添加和刪除操作——比如實現一個消息隊列或緩存系統——那么 collections.deque（雙端隊列）是比 list 更高效的選擇。
想象一下早高峰地鐵站的進出閘機，list就像是只有一側可以進出的單行道，每次從前面插隊或離開，后面的人都得跟著挪動；而deque則像是兩側都有閘機的雙行道，進出互不影響，效率自然更高。
場景：實現一個日志隊列，只保留最新的N條記錄。
from collections import deque# 使用列表作為隊列 (在頭部插入/刪除效率低)
my_list_queue = []
my_list_queue.append(1)
my_list_queue.append(2)
my_list_queue.insert(0, 0) # 在頭部插入，效率低
my_list_queue.pop(0) # 在頭部刪除，效率低# 使用deque作為隊列 (兩端操作高效)
my_deque = deque(maxlen=3) # 設置最大長度為3
my_deque.append(1)
my_deque.append(2)
my_deque.append(3)
print(my_deque) # 輸出: deque([1, 2, 3], maxlen=3)my_deque.append(4) # 自動從另一端移除最舊的元素
print(my_deque) # 輸出: deque([2, 3, 4], maxlen=3)my_deque.appendleft(0) # 在左端添加
print(my_deque) # 輸出: deque([0, 2, 3], maxlen=3)
list 在頭部（索引0）插入和刪除項的開銷較大，因為它需要移動整個列表的內存。而 deque 專門為兩端的高效操作而設計，它是一個線程安全的雙端隊列，底層采用雙向鏈表結構，保證了O(1)時間復雜度的兩端操作。
此外，deque 可以有界（maxlen 參數），當達到最大長度時，新添加的項會自動從另一端丟棄最舊的項，非常適合實現固定大小的滑動窗口或歷史記錄。
生產環境中需注意：雖然
deque支持按索引訪問，但這不是它的強項。如果你需要頻繁隨機訪問中間元素，list可能仍然是更好的選擇。
值得注意的是：
deque在中部刪除項的速度并不快，它的優化主要集中在兩端操作。試圖在中間進行插入或刪除，會失去其性能優勢，應盡量避免此類操作。
5.3 set：當查找變慢時，你該考慮的數據結構
隨著項目數據量增長，用 in 檢查一個元素是否在列表中越來越慢，怎么辦？
這就是 set 的用武之地。它不僅能瞬間完成成員檢查，還能天然去重，是處理“存在性”問題的利器。
場景：檢查一個元素是否在一個大型集合中。
import timelarge_list = list(range(1000000))
large_set = set(range(1000000))# 在列表中檢查
start_time = time.time()
1000000 - 1 in large_list
end_time = time.time()
print(f"List lookup time: {end_time - start_time:.6f} seconds")
# 輸出: List lookup time: 0.005xxx seconds (大致)# 在集合中檢查
start_time = time.time()
1000000 - 1 in large_set
end_time = time.time()
print(f"Set lookup time: {end_time - start_time:.6f} seconds")
# 輸出: Set lookup time: 0.000xxx seconds (大致)
生活化類比：list 查找就像在一堆雜亂的信件里找某一封，你得一封封翻。而 set 就像給所有信件編了號并建立了索引目錄，直接查目錄就能定位，效率天差地別。
值得注意的是：set 的平均查找時間復雜度接近O(1)，這得益于其底層的哈希表實現。但代價是 set 中的元素是無序且唯一的，如果你需要保持插入順序或允許重復，它就不適用了。
5.4 memoryview：處理大文件時的內存救星
當你需要處理一個幾百MB的二進制文件，比如圖像或音頻數據，直接切片 data[1000:2000] 會復制這部分數據，瞬間占用雙倍內存。有沒有辦法避免這種浪費？
memoryview 就是為此而生的。它提供了一個“視圖”，讓你能像操作序列一樣操作內存中的數據，而無需復制。
import arraydata = array.array('i', [1, 2, 3, 4, 5]) # 'i' for signed int
mv = memoryview(data)
print(mv[1:4]) # memoryview of array([2, 3, 4])# 通過memoryview修改原始數據
mv[1] = 100
print(data) # array('i', [1, 100, 3, 4, 5])
生產環境中需注意：memoryview 特別適合與 array.array 或 numpy.ndarray 配合使用，在進行數據預處理、網絡傳輸或與C擴展交互時，能極大減少內存拷貝開銷，提升性能。
memoryview.cast 方法更是強大，它允許你改變數據的解釋方式（例如，將4個字節的int重新解釋為4個單獨的byte），而無需移動任何實際數據，返回的依然是共享原始內存的視圖。
我的經驗是：在處理大量數據時，不要盲目地只使用 list。花時間思考數據的特性和操作模式，選擇最合適的序列類型，往往能帶來意想不到的性能提升和內存優化。
總結
通過本文的探討，我們深入了解了Python序列的豐富世界。從其設計哲學到具體的類型分類，從高效的列表推導式和生成器表達式，到元組的獨特作用，再到序列拆包、模式匹配和切片等高級操作，以及何時選擇 array、deque 或 set 等替代方案，我們旨在幫助你構建更健壯、更高效的Python應用。
你是否曾在性能瓶頸時束手無策，或在內存溢出邊緣掙扎？
這正是我們需要跳出列表舒適區的時候——選擇更合適的序列類型，往往能帶來質的飛躍。
比如array.array就像一塊金屬板，只能刻下同一種字體的字符，但正因如此，它比普通紙張（list）更堅固、更節省空間。當你處理百萬級數值時，這種緊湊存儲的優勢就顯現出來了。特別說明：若涉及科學計算，不妨直接上numpy.ndarray，它才是真正的工業級解決方案。
而collections.deque則像地鐵站的雙向閘機，無論從哪頭進人都能高效通行。它的底層是雙向鏈表，所以在兩端增刪元素都是O(1)的完美性能。不過要注意，隨機訪問會破壞這種效率，別把它當list用。
至于set，它背后的哈希表就像一本精心編排的索引目錄，讓你瞬間定位目標，而不是一頁頁翻找。成員檢查從O(n)降到O(1)，這才是算法級別的優化。
最后memoryview，堪稱零拷貝的“上帝視角”。它不復制數據，而是直接映射內存，處理大文件時能省下海量內存。生產環境中，面對視頻流或大型傳感器數據，這往往是唯一可行的方案。
記住：tuple的“不可變”只是表面功夫——若其元素本身可變，依然可能被修改。這就是所謂的“偽不變性”陷阱，在緩存或字典鍵場景中需格外警惕。
我們下一講見!
