据我所知，Python中的list是用数组实现的，而deque是用双链表实现的。在任何一种情况下，对某个值的二分查找都需要 O(logn) 时间，但如果我们插入到该位置，则数组需要 O(n)，而双链表需要 O(1)。
那么，我们可以使用bisect、insort和deque的组合来实现时间复杂度与Java中的TreeMap相当的所有动态集合操作吗？
更新：我在这个 Leetcode 问题中测试了它：https://leetcode.com/problems/time-based-key-value-store/submissions/
出乎我的意料，当我从list切换到deque时，速度慢了很多。
【问题讨论】：
标签： python python-3.x algorithm binary-search treemap
对于你的标题问题：是的，他们确实如此。
对于您假设的排序集实现问题：不，您不能。
一，你对deque的实现有误；它不是一个简单的“每个节点的项目”链接列表，它是每个节点的 block 项目（CPython 参考解释器上的 64 个，尽管这是一个实现细节）。除了头部和尾部块之外，内部块永远不会留空，因此在deque 的中间插入并不是特别便宜，它仍然需要移动一堆东西。这不是O(n) 像中间list 插入，因为它利用了一些旋转效率来旋转，附加到一侧或另一侧，然后旋转回来，但它与在已知点插入相去甚远一个链表，剩下的O(n)（尽管有很大的常数除数，因为洗牌整个块比移动每个单独的项目便宜）。
两个，deque 中的每个查找都是 O(n)，而不是像 list 那样的 O(1)；如前所述，它有一个 64 的常数除数，它在 deque 的任一端附近下降到 O(1)，但它通常仍然是 O(n)，对于大型 deques 的扩展性很差。 bisect 搜索是 O(log n) 假设索引序列是 O(1);对于deque，它们将是O(n log n)，因为它们将执行log nO(n) 索引操作。这与您的测试结果相符； bisect+deque 明显更差。
Java 的TreeMap 无论如何都不是根据二分查找和链表实现的；链表对此没有好处，因为最终完整的二进制搜索必须来回遍历足够多的时间才能完成O(n) 的总工作，即使它只需要与O(log n) 元素进行比较。树状图需要某种树状结构，你不能用链表和好的算法来伪造它。
内置替代方案包括：
insort of a normal list：当然是O(n)，但昂贵的部分（寻找插入位置）是O(log n)，它只是“腾出空间”步骤O(n)，它是一个真的便宜O(n)（基本上是memcpy）。对于真正巨大的 lists 来说是不可接受的，但您会惊讶地发现，在 Python 的缓慢导致开销明显之前，您需要多大的 list。sort。当输入已经大部分排序时，TimSort 算法非常做得很好（与没有优化部分排序的通用排序相比，更接近O(n)），所以它可能没问题。李>
heapq 模块可以通过真正的 O(log n) 插入和删除来做到这一点，并通过 O(1) 获得最小值（它总是索引 0）。sqlite3 数据库（可能通过shelve），根据需要进行索引； sqlite3 索引默认使用 B 树，这意味着使用索引键排序的查询“免费”以排序顺序返回结果。否则，您必须安装一个第三方模块，该模块提供正确排序的set-like 类型。
【讨论】：
sort使用TimSort。