成都网站建设桔子科技,延安做网站的公司,域名是建网站之前申请吗,设计平台官网一个Python字典表达式谜题让我们探究一下下面这个晦涩的python字典表达式#xff0c;以找出在python解释器的中未知的内部到底发生了什么。# 一个python谜题#xff1a;这是一个秘密# 这个表达式计算以后会得到什么结果#xff1f;{True: yes, 1: no, 1.0: mayb…一个Python字典表达式谜题让我们探究一下下面这个晦涩的python字典表达式以找出在python解释器的中未知的内部到底发生了什么。# 一个python谜题这是一个秘密# 这个表达式计算以后会得到什么结果{True: yes, 1: no, 1.0: maybe}有时候你会碰到一个很有深度的代码示例 --- 哪怕仅仅是一行代码但是如果你能够有足够的思考它可以教会你很多关于编程语言的知识。这样一个代码片段就像是一个Zen kōan一个在修行的过程中用来质疑和考验学生进步的问题或陈述。译者注Zen kōan,大概就是修行的一种方式详情见wikipedia我们将在本教程中讨论的小代码片段就是这样一个例子。乍看之下它可能看起来像一个简单的词典表达式但是仔细考虑时通过cpython解释器它会带你进行一次思维拓展的训练。我从这个短短的一行代码中得到了一个启发而且有一次在我参加的一个Python会议上我还把作为我演讲的内容并以此开始演讲。这也激发了我的python邮件列表成员间进行了一些积极的交流。所以不用多说就是这个代码片。花点时间思考一下下面的字典表达式以及它计算后将得到的内容{True: yes, 1: no, 1.0: maybe}在这里,我先等会儿大家思考一下...5...4...3...2...1...OK, 好了吗这是在cpython解释器交互界面中计算上述字典表达式时得到的结果{True: yes, 1: no, 1.0: maybe}{True: maybe}我承认当我第一次看到这个结果时我很惊讶。但是当你逐步研究其中发生的过程时这一切都是有道理的。所以让我们思考一下为什么我们得到这个 - 我想说的是出乎意料 - 的结果。这个子字典是从哪里来的当python处理我们的字典表达式时它首先构造一个新的空字典对象;然后按照字典表达式给出的顺序赋键和值。因此当我们把它分解开的时候我们的字典表达就相当于这个顺序的语句xs dict()xs[True] yesxs[1] noxs[1.0] maybe奇怪的是Python认为在这个例子中使用的所有字典键是相等的True 1 1.0TrueOK但在这里等一下。我确定你能够接受1.0 1但实际情况是为什么True也会被认为等于1呢我第一次看到这个字典表达式真的让我难住了。在python文档中进行一些探索之后我发现python将bool作为了int类型的一个子类。这是在Python 2和Python 3的片段“The Boolean type is a subtype of the integer type, and Boolean values behave like the values 0 and 1, respectively, in almost all contexts, the exception being that when converted to a string, the strings ‘False’ or ‘True’ are returned, respectively.”“布尔类型是整数类型的一个子类型在几乎所有的上下文环境中布尔值的行为类似于值0和1例外的是当转换为字符串时会分别将字符串”False“或”True“返回。“(原文)是的这意味着你可以在编程时上使用bool值作为Python中的列表或元组的索引[no, yes][True]yes但为了代码的可读性起见您不应该类似这样的来使用布尔变量。(也请建议你的同事别这样做)Anyway让我们回过来看我们的字典表达式。就python而言True1和1.0都表示相同的字典键。当解释器计算字典表达式时它会重复覆盖键True的值。这就解释了为什么最终产生的字典只包含一个键。在我们继续之前让我们再回顾一下原始字典表达式{True: yes, 1: no, 1.0: maybe}{True: maybe}这里为什么最终得到的结果是以True作为键呢由于重复的赋值最后不应该是把键也改为1.0了经过对cpython解释器源代码的一些模式研究我知道了当一个新的值与字典的键关联的时候python的字典不会更新键对象本身ys {1.0: no}ys[True] yesys{1.0: yes}当然这个作为性能优化来说是有意义的 --- 如果键被认为是相同的那么为什么要花时间更新原来的在最开始的例子中你也可以看到最初的True对象一直都没有被替换。因此字典的字符串表示仍然打印为以True为键(而不是1或1.0)。就目前我们所知而言似乎看起来像是结果中字典的值一直被覆盖只是因为他们的键比较后相等。然而事实上这个结果也不单单是由__eq__比较后相等就得出的。等等那哈希值呢python字典类型是由一个哈希表数据结构存储的。当我第一次看到这个令人惊讶的字典表达式时我的直觉是这个结果与散列冲突有关。哈希表中键的存储是根据每个键的哈希值的不同包含在不同的“buckets”中。哈希值是指根据每个字典的键生成的一个固定长度的数字串用来标识每个不同的键。(哈希函数详情)这可以实现快速查找。在哈希表中搜索键对应的哈希数字串会快很多而不是将完整的键对象与所有其他键进行比较来检查互异性。然而通常计算哈希值的方式并不完美。并且实际上会出现不同的两个或更多个键会生成相同的哈希值并且它们最后会出现在相同的哈希表中。如果两个键具有相同的哈希值那就称为哈希冲突(hash collision)这是在哈希表插入和查找元素时需要处理的特殊情况。基于这个结论哈希值与我们从字典表达中得到的令人意外的结果有很大关系。所以让我们来看看键的哈希值是否也在这里起作用。我定义了这样一个类来作为我们的测试工具classAlwaysEquals:def__eq__(self,other):return Truedef__hash__(self):return id(self)这个类有两个特别之处。第一因为它的__eq__魔术方法(译者注双下划线开头双下划线结尾的是一些Python的“魔术”对象)总是返回true所以这个类的所有实例和其他任何对象都会恒等AlwaysEquals() AlwaysEquals()TrueAlwaysEquals() 42TrueAlwaysEquals() waaat?True第二每个Alwaysequals实例也将返回由内置函数id()生成的唯一哈希值值objects [AlwaysEquals(),AlwaysEquals(),AlwaysEquals()][hash(obj) for obj in objects][4574298968, 4574287912, 4574287072]在CPython中id()函数返回的是一个对象在内存中的地址并且是确定唯一的。通过这个类我们现在可以创建看上去与其他任何对象相同的对象但它们都具有不同的哈希值。我们就可以通过这个来测试字典的键是否是基于它们的相等性比较结果来覆盖。正如你所看到的下面的一个例子中的键不会被覆盖即使它们总是相等的{AlwaysEquals(): yes, AlwaysEquals(): no}{ : yes,: no }下面我们可以换个思路如果返回相同的哈希值是不是就会让键被覆盖呢classSameHash:def__hash__(self):return 1这个SameHash类的实例将相互比较一定不相等但它们会拥有相同的哈希值1a SameHash()b SameHash()a bFalsehash(a), hash(b)(1, 1)一起来看看python的字典在我们试图使用SameHash类的实例作为字典键时的结果{a: a, b: b}{ : a,: b }如本例所示“键被覆盖”的结果也并不是单独由哈希冲突引起的。Umm..好吧,可以得到什么结论呢?检查python字典对象中两个 key 是否相同的条件是二者的相等性(__eq__)以及hash值对比(__hash__)是否相等。那我们就来总结一下上述讨论的结果{trueyes1no1.0maybe} 字典表达式计算结果为 {truemaybe}是因为键 true1 和 1.0 都是相等的并且它们都有相同的哈希值True 1 1.0True(hash(True), hash(1), hash(1.0))(1, 1, 1)也许并不那么令人惊讶这就是我们为何得到这个结果作为字典的最终结果的原因{True: yes, 1: no, 1.0: maybe}{True: maybe}我们在这里涉及了很多方面内容而这个特殊的python技巧起初可能有点令人难以置信 --- 所以我一开始就把它比作是Zen kōan。如果很难理解本文中的内容请尝试在Python交互环境中逐个去检验一下代码示例。你会收获一些关于python深处知识。
