怎麼用Python寫出随時間變化的字_Python 容器使用的 5 個技巧和 2 個誤區

每天 11:40 準時為你分享

文 | [email protected] 公衆号

編輯 | EarlGrey

程式設計派公衆号授權釋出

“容器”這兩個字很少被 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

子產品:

>>> from collections import OrderedDict

>>> list(OrderedDict.fromkeys(l).keys())

[10, 2, 3, 21]

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

傳回一個生成器。而不是修改被疊代的清單或是字典對象本身。

總結

在這篇文章中，我們首先從“容器類型”的定義出發，在底層和高層兩個層面探讨了容器類型。之後遵循系列文章傳統，提供了一些編寫容器相關代碼時的技巧。

讓我們最後再總結一下要點：

• 了解容器類型的底層實作，可以幫助你寫出性能更好的代碼
• 提煉需求裡的抽象概念，面向接口而非實作程式設計
• 多使用“懶惰”的對象，少生成“迫切”的清單
• 使用元組和字典可以簡化分支代碼結構
• 使用 

  next()

   函數配合疊代器可以高效完成很多事情，但是也需要注意“枯竭”問題
• collections、itertools 子產品裡有非常多有用的工具，快去看看吧！

看完文章的你，有沒有什麼想吐槽的？請留言或者在 項目 Github Issues 告訴我吧。

注解

1. Python 這門語言除了 CPython 外，還有許許多多的其他版本實作。如無特别說明，本文以及 “Python 工匠” 系列裡出現的所有 Python 都特指 Python 的 C 語言實作 CPython
2. Python 裡沒有類似其他程式設計語言裡的“Interface 接口”類型，隻有類似的“抽象類”概念。為了表達友善，後面的内容均統一使用“接口”來替代“抽象類”。
3. 有沒有隻實作了 Mapping 但又不是 MutableMapping 的類型？試試 MappingProxyType({})
4. 有沒有隻實作了 Set 但又不是 MutableSet 的類型？試試 frozenset()

回複下方「關鍵詞」，擷取優質資源

回複關鍵詞「 pybook03」，立即擷取首頁君與小夥伴一起翻譯的《Think Python 2e》電子版

回複關鍵詞「pybooks02」，立即擷取 O'Reilly 出版社推出的免費 Python 相關電子書合集

回複關鍵詞「書單02」，立即擷取首頁君整理的 10 本 Python 入門書的電子版

印度小夥寫了套深度學習教程，Github上星标已經5000+

GitHub熱榜第四！這套Python機器學習課，免費擷取還易吸收

《流暢的 Python》到底好在哪？

如何系統化學習 Python ？

GitHub标星2.6萬！Python算法新手入門大全

使用 Vue.js 和 Flask 實作全棧單頁面應用

Python 實作一個自動化翻譯和替換的工具

使用 Python 制作屬于自己的 PDF 電子書

12步輕松搞定Python裝飾器

200 行代碼實作 2048 遊戲

題圖：pexels，CC0 授權。