在Python 3.6+中是否订购了字典？
它们是插入顺序[1]。从Python 3.6开始，对于Python的CPython实现，字典会记住插入项目的顺序。这在Python 3.6中被视为实现细节；你需要使用OrderedDict，如果你想多数民众赞成插入排序保证不同的Python的其它实现（与其他有序行为[1] ）。
从Python 3.7开始，这不再是实现细节，而是成为一种语言功能。从GvR的python-dev消息中：
做到这一点。裁定“裁定保留插入顺序”。谢谢！
这只是意味着您可以依靠它。如果其他Python实现希望成为Python 3.7的一致实现，则还必须提供插入顺序字典。
在保留元素顺序的同时，Python3.6字典实现如何比旧的实现更好的性能[2]？
本质上，通过保留两个数组。
第一个数组，按插入顺序dk_entries保存字典的条目（类型PyDictKeyEntry）。保留顺序是通过仅附加数组来实现的，在该数组中始终在末尾插入新项（插入顺序）。
第二个
dk_indices
保留dk_entries
数组的索引（即，指示中相应条目位置的值dk_entries
）。该数组充当哈希表。当对密钥进行哈希处理时，它会导致存储在其中的索引之一，dk_indices
并且通过indexing
获取相应的条目dk_entries
。由于只有索引被保留，此数组的类型取决于字典的整体大小（范围从类型int8_t
（1字节）到int32_t/ int64_t
（4/8字节）上32/64位构建）
在以前的实现中，必须分配类型
PyDictKeyEntry和大小的稀疏数组
dk_size。不幸的是，由于性能原因，该数组不允许太
2/3 * dk_size满，这也导致了很多空白。（并且空白区域仍具有大小！）。PyDictKeyEntry
现在不是这种情况，因为仅存储了必需的条目（已插入的条目），并且保留了一个类型稀疏的数组
intX_t（X取决于dict的大小）2/3 * dk_size。空格从类型更改
PyDictKeyEntry为intX_t。
因此，显然，创建一个稀疏类型的数组
PyDictKeyEntry比存储
ints的稀疏数组需要更多的内存。
如果有兴趣，可以在Python-Dev上查看有关此功能的完整对话，这是一本好书。
在Raymond Hettinger提出的原始建议中，可以看到所使用的数据结构的可视化效果，该可视化体现了该思想的要旨。
例如，字典：
d = {'timmy': 'red', 'barry': 'green', 'guido': 'blue'}当前存储为[keyhash，key，value]：
entries = [['--', '--', '--'],[-8522787127447073495, 'barry', 'green'],['--', '--', '--'],['--', '--', '--'],['--', '--', '--'],[-9092791511155847987, 'timmy', 'red'],['--', '--', '--'],[-6480567542315338377, 'guido', 'blue']]
相反，数据应按以下方式组织：
indices = [None, 1, None, None, None, 0, None, 2]entries = [[-9092791511155847987, 'timmy', 'red'], [-8522787127447073495, 'barry', 'green'], [-6480567542315338377, 'guido', 'blue']]
正如您现在可以从视觉上看到的那样，在原始建议中，很多空间实际上是空的，以减少冲突并加快查找速度。使用新方法，可以通过将稀疏移动到真正需要的索引中来减少所需的内存。
[1]：我说“插入有序”而不是“有序”，因为在存在OrderedDict的情况下，“有序”暗示了dict对象不提供的其他行为。OrderedDicts是可逆的，提供顺序敏感的方法，并且主要是，提供一个订单sensive相等测试（==，!=）。dict目前不提供任何这些行为/方法。
[2]：通过更加紧凑的设计，新的字典实现在内存方面表现更好；这是这里的主要好处。在速度方面，差异并不那么明显，在某些地方，新dict可能会引入轻微的回归（例如，关键查找），而在其他地方（想到迭代和调整大小），则应该提高性能。
总体而言，由于引入的紧凑性，字典的性能（特别是在现实生活中）得以提高。
