[Python-ideas] dictionary constructor should not allow duplicate keys

[Michael Selik]

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:
>
> 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).


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
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160504/c81c04bd/attachment.html>