解释一
python的字符串hash算法并不是直接遍历字符串每个字符去计算hash，而是会有一个secret prefix和一个secret suffix，可以认为相当于是给字符串加盐后做hash，可以规避一些规律输入的情况
显然这个secret前后缀的值会直接影响计算结果，而且它有一个启动时随机生成的机制，只不过，在2.x版本中，这个机制默认是关闭的，前后缀每次启动都设置为0，除非你改了相关环境变量来要求随机，而在3.x中修改了默认行为，如果你不配置环境变量，则默认是随机一个前后缀值，这样每次启动都会不同
这个环境变量是PYTHONHASHSEED，无论在2.x还是3.x中，配置为一个正整数，将作为随机种子；配置为0，则secret前后缀默认清零（和2.x默认行为就一样了），配置为空串或“random”，则表示让进程随机生成（和3.x默认行为一样）
具体为啥要这么做，猜测一个是为了安全性（防字符串hash表的攻击，比如php曾经碰到的攻击），另一个可能也是强调不要依赖一些内建结果，因为这种算法可能随着版本而更新，避免有些用户不看文档，误以为是永远不变的
作者：冒泡
链接：https://www.zhihu.com/question/57526436/answer/153241020
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
解释二
set/dict的hash还真就是这个玩意实现的，因为它保证了在同一个解释器进程里相同字符串hash一致。
因为CPython 3.x里的str，它的实体是unicode对象，实体是个utf-8 bytes或者是wstr（嗯这里真特么有个『或者』），并且通过一个叫做unicodedata_db的玩意来实现缓存（不然就没法儿保证str对象的不可变与地址一致性了）。
于是乎当你调内部hash的时候，反正不同进程中的解释器不会共用一个unicodedata_db，这个解释器进程里的字符串的hash到另一个进程里指不定连个字符串都不是，所以在计算这个内部hash的时候加入了一个code_magic的玩意，同时也均摊了一把复杂度，省得这个db以及set/dict对特定数据表现出极差性能。再说了，谁也不会傻到拿个解释器内部hash去做跨进程交换。
所以真需要做可重现可跨进程保持一致性的hash，请用hashlib。
作者：Coldwings
链接：https://www.zhihu.com/question/57526436/answer/153238652
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。