当字典键相同时，为什么Python仅保留最后一个键值对？ [英] When dictionary keys are identical, why does Python keep only the last key-value pair?

问题描述

假设我创建了一个字典 a_dictionary ，其中两个键值对具有相同的键：

 在[1]中：a_dictionary = {'key'：5，5，'another_key'：10，'key'：50} 
 
在[2]：a_dictionary 
 Out [2]：{'key'：50，'another_key'：10} 
  

为什么Python在这里选择保留最后一个键/值对，而不是抛出有关使用相同键的错误（或至少发出警告）？

我的方式看到它，这里的主要缺点是您可能会丢失数据而没有意识到。

（如果相关的话，我在Python 3.6.4上运行了上面的代码。）

解决方案

如果您的问题是为什么Python dict显示器最初是按这种方式设计的……可能没人知道。

---

我们知道何时做出决定。 Python 0.9.x（1991-1993）没有字典显示； Python 1.0.x（1994）做到了。他们的工作与今天完全一样。从文档中： ¹

词典显示将产生一个新的词典对象。

从左到右评估键/基准对以定义字典的
条目：每个键对象都用作
字典中的键以存储对应的

键值类型的限制已在
节类型中列出。

未检测到重复键之间的冲突；以给定键
值存储的最后
数据（在文本上最右边）为准。

，对其进行测试：

  $ ./python 
 Python 1.0.1（2018年8月21日）
版权1991-1994年，Stichting Mathematisch Centrum，阿姆斯特丹
>> {'key'：1，'other'：2，2，'key'：3} 
 {'other'：2，'key'：3} 
  

---

但是没有提及Guido为什么选择这种设计：

• 1.0文档。


• 设计与开发；历史常见问题解答。


• Guido的 Python的历史博客。


• 在我能想到的其他任何地方都可能有它。

此外，如果您查看了具有相似功能的不同语言，其中有些保留了像Python这样的最后一个键值对，有些保留了任意键值对，有些则引发了某种错误……每种语言都有足够的内容，您不能说这是一个显而易见的设计，这就是Guido选择它的原因。

---

如果您想要一个疯狂的猜想，那就比这更好您可以自己猜测的是我的：

编译器不仅有效，而且有效通过创建一个空的dict并在其中插入键值对来从文字中构造const值。因此，默认情况下，您将获得重复项允许的，最后键赢得的语义；如果您还需要其他任何内容，则必须编写额外的代码。而且，由于没有明显的理由互相挑剔，Guido选择不编写额外的代码。

---

因此，如果设计没有令人信服的理由，为什么没有人尝试更改

嗯，有人提出了功能请求（ bpo＃16385 ），以使重复键成为3.4中的错误。
，但当它被提示将其引入-想法时显然消失了。）它可能已经出现了几次，但显然没有人想要

与此同时，他与Python现有行为的实际参数最接近的是Terry J. Reedy的评论：

如果没有更多的用例和支持（来自关于python-ideas的讨论），我认为这应该被拒绝。能够重新编写键是Python字典的基础，也是为什么它们可用于Python的可变名称空间。一次写一次或一次写一次密钥的字典将是另一回事。

对于文字，代码生成器可能依赖于能够编写重复的密钥而不必返回并清除先前的输出。

---

_{1。我不认为1.0的文档可以在任何地方直接链接，但是您可以下载整个1.0.1源档案，并从TeX源构建文档。}

Let's say I create a dictionary a_dictionary where two of the key-value pairs have an identical key:

In [1]: a_dictionary = {'key': 5, 'another_key': 10, 'key': 50} 

In [2]: a_dictionary
Out[2]: {'key': 50, 'another_key': 10}

Why does Python choose here to keep the last key-value pair instead of throwing an error (or at least raising a warning) about using identical keys?

The way I see it, the main downside here is that you may lose data without being aware.

(If it's relevant, I ran the code above on Python 3.6.4.)

解决方案

If your question is why Python dict displays were originally designed this way… Probably nobody knows.

---

We know when the decision was made. Python 0.9.x (1991-1993) didn't have dict displays; Python 1.0.x (1994) did. And they worked exactly the same as they do today. From the docs:¹

A dictionary display yields a new dictionary object.

The key/datum pairs are evaluated from left to right to define the entries of the dictionary: each key object is used as a key into the dictionary to store the corresponding datum.

Restrictions on the types of the key values are listed earlier in section types.

Clashes between duplicate keys are not detected; the last datum (textually rightmost in the display) stored for a given key value prevails.

And, testing it:

$ ./python
Python 1.0.1 (Aug 21 2018)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
>>> {'key': 1, 'other': 2, 'key': 3}
{'other': 2, 'key': 3}

---

But there's no mention of why Guido chose this design in:

• The 1.0 docs.
• The Design & History FAQ.
• Guido's History of Python blog.
• Anywhere else I can think of that might have it.

Also, if you look at different languages with similar features, some of them keep the last key-value pair like Python, some keep an arbitrary key-value pair, some raise some kind of error… there are enough of each that you can't argue that this was the one obvious design and that's why Guido chose it.

---

If you want a wild guess that's probably no better than what you could guess on your own, here's mine:

The compiler not only could, but does, effectively construct const values out of literals by creating an empty dict and inserting key-values pairs into it. So, you get duplicates-allowed, last-key-wins semantics by default; if you wanted anything else, you'd have to write extra code. And, without a compelling reason to pick one over another, Guido chose to not write extra code.

---

So, if there's no compelling reason for the design, why has nobody tried to change it in the 24 years since?

Well, someone filed a feature request (b.p.o. #16385), to made duplicate keys an error in 3.4. but apparently went away when it was suggested it bring it up on -ideas.) It may well have come up a few others times, but obviously nobody wanted it changed badly enough to push for it.

Meanwhile, he closest thing to an actual argument for Python's existing behavior is this comment by Terry J. Reedy:

Without more use cases and support (from discussion on python-ideas), I think this should be rejected. Being able to re-write keys is fundamental to Python dicts and why they can be used for Python's mutable namespaces. A write-once or write-key-once dict would be something else.

As for literals, a code generator could depend on being able to write duplicate keys without having to go back and erase previous output.

---

_{1. I don't think the docs for 1.0 are directly linkable anywhere, but you can download the whole 1.0.1 source archive and build the docs from the TeX source.}

这篇关于当字典键相同时，为什么Python仅保留最后一个键值对？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！