[Python-ideas] dictionary constructor should not allow duplicate keys
Luigi Semenzato
luigi at semenzato.com
Wed May 4 13:37:00 EDT 2016
It's all about typing and reading.
Suppose Python didn't have a special syntax for dict displays. Then
folks would likely write this:
dict((
(1, 11),
(2, 22),
...
))
but then suppose someone says: "hey, folks do this a lot, let's make
it more convenient" and introduce a curly braces notation, and suppose
it allows overwriting, like it does now.
The new notation exists *exclusively* to make it easier to type and
read dictionaries in the code---by a human. Except that with these
semantics it makes it impossible to detect duplicate key errors, which
the vast majority of users would prefer to notice (a bold and unproven
statement, but a reasonable guess). What's worse, people don't
realize the problem until they have many large dict displays, and many
bugs. So they feel annoyed and betrayed.
Suppose instead that the new notation does NOT allow overwriting. If
folks rely on the overwrite semantics, in either human-written or
machine-generated code, they will immediately notice the problem and
use dict(), with very little inconvenience to code generators. (And
some to the humans, but remember, they are a tiny minority :)
The strict semantics are maybe marginally harder to explain, and maybe
marginally harder to implement, but neither should be a show-stopper.
However, that's not where we are. There is the legacy code issue, and
the legacy mindset. I don't know how to evaluate these issues, and I
don't even know how much experience the community has with
backward-incompatible changes. So, while I am fairly positive that it
would have been a better choice to start with, I have no idea whether,
when, and how this proposal should have any effect.
P.S. The issue of detecting duplicate keys at parse time is
completely separate and it was my mistake to focus on it first.
P.P.S. The issue of whether a set display should allow duplicate
elements is less important, since allowing them does not have
destructive consequences.
More information about the Python-ideas
mailing list