小編典典

它們是插入順序[1]。從Python 3.6開始，對于Python的CPython實現，詞典會記住插入項目的順序。這在Python 3.6中被視為實現細節；你需要使用OrderedDict，如果你想多數民眾贊成插入排序保證不同的Python的其它實現（與其他有序行為[1] ）。

從Python 3.7開始，它不再是實現細節，而是成為一種語言功能。從GvR的py??thon-dev消息中：

做到這一點。裁定“裁定保留插入順序”。謝謝！

這只是意味著你可以依靠它。如果其他Python實現希望成為Python 3.7的一致實現，則還必須提供插入順序字典。

在保留元素順序的同時，Python 3.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']]

正如你現在可以從視覺上看到的那樣，在原始建議中，很多空間實際上是空的，以減少沖突并加快查找速度。使用新方法，可以通過將稀疏移動到真正需要的索引中來減少所需的內存。

2020-02-05

總結

以上是生活随笔為你收集整理的python3.6字典有序_Python-字典是用Python3.6+订购的吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。