当字典键相同时，为什么 Python 只保留最后一个键值对？

Question

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

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

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

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

在我看来，这里的主要缺点是您可能会在不知情的情况下丢失数据。

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

Answer 1

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. 我不认为 1.0 的文档可以在任何地方直接链接，但您可以下载整个 1.0.1 源存档并从 TeX 源构建文档。}