Python コンテナーの使用に関する 5 つのヒントと 2 つの誤解

Python コンテナーの使用に関する 5 つのヒントと 2 つの誤解

「コンテナー」という言葉が Python の技術記事で言及されることはほとんどありません。 「コンテナ」と聞くと、ほとんどの人は小さなシロナガスクジラ、Docker を思い浮かべますが、この記事はそれとは関係ありません。この記事のコンテナーは Python の抽象的な概念であり、他のオブジェクトを保持するために特に使用されるデータ型の一般用語です。

Python には、リスト、タプル、ディクショナリ、セットという 4 つの最も一般的な組み込みコンテナ タイプがあります。これらを個別にまたは組み合わせて使用​​することで、多くのことを効率的に実行できます。

Python 言語自体の内部実装の詳細も、これらのコンテナー タイプと密接に関連しています。たとえば、Python のクラス インスタンス属性、グローバル変数 globals() などはすべて辞書型を通じて保存されます。

この記事では、まずコンテナ タイプの定義から始めて、日常のコーディングのベスト プラクティスをいくつかまとめていきます。次に、各コンテナー タイプが提供する特別な機能に関するプログラミングのヒントをいくつか紹介します。

コンテナについて話すとき、私たちは何を話しているのでしょうか?

先ほど「コンテナ」の簡単な定義を示しました。コンテナは、特に他のオブジェクトを保持するために使用されます。しかし、この定義は広すぎるため、日常のプログラミングに何の指針も提供できません。 Python でコンテナを真にマスターするには、次の 2 つのレベルから始める必要があります:

·基礎となる実装: 組み込みコンテナ タイプで使用されるデータ構造は何ですか?特定の操作はどのように機能するのでしょうか?

· 高レベルの抽象化: オブジェクトがコンテナであるかどうかは何で決まるのでしょうか?コンテナを定義する動作は何ですか?

ここで、これら 2 つの異なるレベルに立って、コンテナについて再理解してみましょう。

下部のコンテナを見てください。

Python は高水準プログラミング言語であり、Python が提供する組み込みコンテナ タイプは高度な技術の結果です。カプセル化と抽象化。 Python の組み込み型の名前は、「リンク リスト」、「赤黒ツリー」、「ハッシュ テーブル」などの名前に比べて、その型の機能的特徴を説明しているだけであり、名前だけでは理解できません。内部の詳細を少しだけ。

これは、Python プログラミング言語の利点の 1 つです。基盤となるコンピューターに近い C などのプログラミング言語と比較して、Python はプログラマーにとってより使いやすい組み込みコンテナー タイプを再設計して実装し、メモリ管理などの追加作業から保護します。より良い開発エクスペリエンスを提供します。

しかし、これが Python 言語の利点であるなら、なぜコンテナ タイプの実装の詳細をわざわざ理解する必要があるのでしょうか?答えは、細部に注意を払うことでコードをより速く書くことができるということです。

コードをより速く書く

1. リストの頻繁な展開や新しいリストの作成を避ける

すべての組み込みコンテナー 型なし容量を制限します。必要に応じて、マシン全体のメモリがいっぱいになるまで、空のリストに数値を増やし続けることができます。

Python 言語の実装詳細では、リストのメモリはオンデマンドで割り当てられます [注 1]。特定のリストが現在所有しているメモリが十分でない場合、メモリ拡張ロジックがトリガーされます。また、メモリの割り当てはコストのかかる操作です。ただし、ほとんどの場合、プログラムのパフォーマンスに重大な影響を与えることはありません。ただし、処理するデータの量が特に大きい場合、メモリ割り当てによりプログラム全体のパフォーマンスが低下しやすくなります。

幸いなことに、Python はこの問題を以前から認識しており、「怠け者になる」という公式の問題解決ガイドラインを提供していました。

「怠け者になる」ことをどう説明しますか? range() 関数の進化は非常に良い例です。

Python 2 では、 range(100000000) を呼び出した場合、結果が得られるまでに数秒待つ必要があります。これは、巨大なリストを返す必要があり、メモリの割り当てと計算に多くの時間を費やすためです。しかし、Python 3 では、同じ呼び出しで結果がすぐに得られます。この関数はリストを返すのではなく、範囲型の遅延オブジェクトを返すため、それを反復処理するかスライスするときにのみ実数を返します。

したがって、パフォーマンスを向上させるために、組み込み関数の範囲は「遅延」になります。頻繁すぎるメモリ割り当てを避けるために、日常のコーディングでは、関数も遅延させる必要があります。これには次のものが含まれます。

yield キーワードをさらに使用し、ジェネレーター オブジェクトを返す

·

リスト導出式の代わりにジェネレーター式を使用してみてください。

·

ジェネレーター式: (iforinrange(100))

·

リスト導出式: [iforinrange(100)]

·

モジュールによって提供される遅延オブジェクトを使用してみます:

·

re.findall の代わりに re.finditer を使用します

反復可能なファイル オブジェクトを直接使用します: forlineinfp.readlines() の代わりに forlineinfp

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) であるためです。これは、ディクショナリとセットの両方がハッシュ テーブル データ構造に基づいて実装されているためです。

# 这个例子不是特别恰当，因为当目标集合特别小时，使用集合还是列表对效率的影响微乎其微
# 但这不是重点 :)
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!")

ヒント: 一般的なコンテナ タイプの時間計算量について詳しく知るには、「TimeComplexity - Python Wiki」を読むことを強くお勧めします。

辞書の実装の詳細に興味がある場合は、Raymond Hettinger の講演「Modern Dictionaries (YouTube)」を視聴することを強くお勧めします。

関連する推奨事項: 「Python 入門チュートリアル##」 #"

コンテナの概要

Python は「アヒル型」言語です。「アヒルのように歩き、アヒルのように泳ぐ鳥を見ると、 「アヒルのように、この鳥もアヒルと呼ぶことができます。」 したがって、オブジェクトの型を言うとき、実際には、このオブジェクトがその型の特定のインターフェイス仕様を満たしており、これを使用すると見なすことができることを意味します。タイプ。すべての組み込みコンテナー タイプについても同じことが当てはまります。

コレクション モジュールの下にある abc (「Abstract Base Classes」の略語) サブモジュールを開くと、コンテナ関連のすべてのインターフェイス (抽象クラス) [注 2] 定義が見つかります。組み込みのコンテナー タイプがどのようなインターフェイスを満たすかを見てみましょう:

·List: Iterable、Sequence、MutableSequence およびその他のインターフェイスを満たす

·タプル: Iterable、Sequence を満たす

·Dictionary (dict): Iterable、Mapping、MutableMapping を満たす [注 3]

·Set : Iterable、Set、MutableSet を満たす [注 4]

各組み込みコンテナ型は、実際には複数のインターフェイス定義を満たす複合エンティティです。たとえば、すべてのコンテナ タイプは「Iterable」インターフェイスを満たします。これは、それらがすべて「Iterable」であることを意味します。しかし逆に言えば、すべての「反復可能な」オブジェクトがコンテナであるわけではありません。文字列は反復可能ですが、通常はそれを「コンテナ」として扱いません。

この事実を理解した後、Python でのオブジェクト指向プログラミングの最も重要な原則の 1 つである、特定の実装ではなくインターフェイスのためのプログラミングを再理解します。

例を使用して、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)))

新しい関数では、依存パラメーターの型をリストから反復可能な抽象クラスに変更しました。これを行うことには多くの利点がありますが、最も明白な利点の 1 つは、コメントがリスト、タプル、ファイルのいずれからのものであっても、新しい関数は次の条件を簡単に満たすことができることです。

# 处理放在元组里的评论
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)

特定のコンテナからの依存関係を変更するtype インターフェイスを抽象化すると、関数の適用範囲が広がります。さらに、新機能は実行効率の面でもさらなるメリットをもたらします。さて、前の質問に戻りましょう。高レベルの観点から見ると、コンテナとは何で定義されるのでしょうか?

答案是：各个容器类型实现的接口协议定义了容器。不同的容器类型在我们的眼里，应该是 是否可以迭代、 是否可以修改、 有没有长度 等各种特性的组合。我们需要在编写相关代码时，更多的关注容器的抽象属性，而非容器类型本身，这样可以帮助我们写出更优雅、扩展性更好的代码。

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 コンテナーの使用に関する 5 つのヒントと 2 つの誤解の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。