为什么字典排序是不确定的？

问题描述：

我最近从 Python 2.7 切换到了 Python 3.3，似乎在 Python 2 中字典键的顺序是任意但一致的，而在 Python 3 中，使用例如获得的字典的键的顺序vars()似乎是不确定的。

如果我运行：

class Test(object): pass
parameters = vars(Test)
print(list(parameters.keys()))

在 Python 2.7 和 Python 3.3 中，则：

• Python 2.7 总是给我

['__dict__', '__module__', '__weakref__', '__doc__']

• 使用 Python 3.3，我可以获得任何随机顺序 — — 例如：

['__weakref__', '__module__', '__qualname__', '__doc__', '__dict__']
['__doc__', '__dict__', '__qualname__', '__module__', '__weakref__']
['__dict__', '__module__', '__qualname__', '__weakref__', '__doc__']
['__weakref__', '__doc__', '__qualname__', '__dict__', '__module__']

这种不确定性从何而来？为什么

list({str(i): i for i in range(10)}.keys())

… 每次跑步都保持一致，始终给予

['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']

…？

解决方案 1：

更新：在 Python 3.6 中，dict有一个新的实现可以保留插入顺序。从 Python 3.7 开始，这种保留顺序的行为得到保证：

dict对象的插入顺序保存特性已被宣布为 Python 语言规范的正式组成部分。

这是2012 年安全修复的结果，在 Python 3.3 中默认启用（向下滚动到“安全改进”）。

公告内容如下：

哈希随机化会导致字典和集合的迭代顺序不可预测，并且在 Python 运行过程中会有所不同。Python 从未保证过字典或集合中键的迭代顺序，建议应用程序永远不要依赖它。从历史上看，字典迭代顺序在各个版本之间变化不大，并且在 Python 的连续执行中始终保持一致。因此，一些现有应用程序可能依赖于字典或集合排序。由于这一点以及许多不接受不受信任输入的 Python 应用程序不易受到此攻击的事实，在此处提到的所有稳定 Python 版本中，哈希随机化默认处于禁用状态。

如上所述，最后一个大写位在 Python 3.3 中不再成立。

另请参阅： object.__hash__()文档（“注释”侧栏）。

PYTHONHASHSEED如果绝对必要的话，您可以通过将环境变量设置为 来禁用受此行为影响的 Python 版本中的哈希随机化0。

你的反例：

list({str(i): i for i in range(10)}.keys())

…实际上在 Python 3.3 中并不总是给出相同的结果，尽管由于处理哈希冲突的方式，不同排序的数量是有限的：

$ for x in {0..999}
> do
>   python3.3 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
     61 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
     73 ['1', '0', '3', '2', '5', '4', '7', '6', '9', '8']
     62 ['2', '3', '0', '1', '6', '7', '4', '5', '8', '9']
     59 ['3', '2', '1', '0', '7', '6', '5', '4', '9', '8']
     58 ['4', '5', '6', '7', '0', '1', '2', '3', '8', '9']
     55 ['5', '4', '7', '6', '1', '0', '3', '2', '9', '8']
     62 ['6', '7', '4', '5', '2', '3', '0', '1', '8', '9']
     63 ['7', '6', '5', '4', '3', '2', '1', '0', '9', '8']
     60 ['8', '9', '0', '1', '2', '3', '4', '5', '6', '7']
     66 ['8', '9', '2', '3', '0', '1', '6', '7', '4', '5']
     65 ['8', '9', '4', '5', '6', '7', '0', '1', '2', '3']
     53 ['8', '9', '6', '7', '4', '5', '2', '3', '0', '1']
     62 ['9', '8', '1', '0', '3', '2', '5', '4', '7', '6']
     52 ['9', '8', '3', '2', '1', '0', '7', '6', '5', '4']
     73 ['9', '8', '5', '4', '7', '6', '1', '0', '3', '2']
     76 ['9', '8', '7', '6', '5', '4', '3', '2', '1', '0']

正如在这个答案开头所指出的，在 Python 3.6 中不再存在这种情况：

$ for x in {0..999}
> do
>   python3.6 -c "print(list({str(i): i for i in range(10)}.keys()))"
> done | sort | uniq -c
   1000 ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']

解决方案 2：

但请注意，Python 3.7 仍然具有非确定性集合。字典保留插入顺序，但集合不保留。集合可以表现出相同的随机行为。

python3 -c "print({str(i) for i in range(9)})"

每次运行仍然会产生不同的结果。