[Python-ideas] dictionary constructor should not allow duplicate keys
michael.selik at gmail.com
Wed May 4 13:59:00 EDT 2016
On Wed, May 4, 2016, 1:37 PM Luigi Semenzato <luigi at semenzato.com> wrote:
> It's all about typing and reading.
> Suppose Python didn't have a special syntax for dict displays. Then
> folks would likely write this:
> (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).
I'm part of the minority(?) that doesn't care. I hope that helps adjust
your odds ratio for that 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 :)
Even a tiny minority of the Python community might be thousands of people.
> 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.
Well, there's that transition from 2 to 3. You do that a few times and you
get a reputation for instability.
I like to imagine a hidden line in the Zen of Python. Between the title and
"Beautiful is better..." I mentally insert, "Backwards compatibility is
important." How important, well, that's why it's Zen and not Rules.
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.
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas