`bytearray`はPythonのZenと矛盾していませんか？

Question

Python PEP 3137は、可変8ビット配列型としてbytearrayを導入しました。しかし、変更可能なbytesタイプのlistは同じ目標を達成し、実際はbetterperformanceですが、おそらくは控えめな構文です。この新しいタイプは、これと矛盾します。Zen of Python

これを実行するには、1つの方法が必要です。

だから私の質問は：bytearraybytesのlist上を使用するための任意の文書化の主な利点や設計上の考慮事項はありますか？

これまでのところ、私はPEPやドキュメンテーションのページに記載された動機を見つけられませんでした。実際には、ドキュメントがほぼ等しくなるようにそれらを扱います：

のByteArray型は、可変シーケンスの通常の方法のほとんどを持っている範囲内の整数のミュータブルなシーケンス0 < = X < 256です...

そして、

リストとのByteArrayオブジェクトは、オブジェクトの変更を可能にする追加の操作をサポートしています。他の変更可能なシーケンス型（言語に追加された場合）も、これらの操作をサポートする必要があります。

bytearrayとしてsは静的に型付けされている（8ビット符号なし整数として）1は、性能向上を期待するが、逆上述したように、おそらく本当であるかもしれません。また、listがbytesを超えるメモリの利点はありません。私はitertools.chainスタイルの可変型にする必要があると想像することができましたが、これはどこにも言及されておらず、設計目標のようではありません。

Answer 1

最初に、それをシームレスに反復できるオブジェクトシーケンス（実際にはitertools.chainが提供するもの）のためのlistスタイルのコンテナが間違いなく便利です。 PEP 3137に記載されているように、array moduleはこの目的のために機能していた可能性がありますが、「理想とはかけ離れていました」。

著者は「可変と不変の両方のバイトタイプ」を望んでいました。これは、設計目標が可変（おそらく高速挿入と削除のために連続していないメモリを使用する）と、不変（間違いなく連続したメモリ）の実装である。これは、私が理解できる限り、array.array、bytes、bytearray、str、unicode、list、tupleおよびgeneratorを含む混乱の種を作成しました。本質的には、メモリに格納されたり、オンザフライ（ジェネレータ）で評価される、静的に型付けされたタイプ、可変または変更不可能なシーケンスへのインタフェースを提供します。これらのほとんどはAbstract Base Classesの論理的根拠に従っていますが、私はこれがPythonicとみなされる前に行われるべきより多くの設計があると思います。

注：私は人々が洞察力や訂正に貢献してくれることを期待して、この回答を編集用に残しておきます。