On Wed, May 4, 2016, 1:37 PM Luigi Semenzato
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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/