<div class="gmail_quote"><div dir="ltr">On Wed, May 4, 2016, 1:37 PM Luigi Semenzato <<a href="mailto:luigi@semenzato.com">luigi@semenzato.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's all about typing and reading.<br>
<br>
Suppose Python didn't have a special syntax for dict displays. Then<br>
folks would likely write this:<br>
<br>
dict((<br>
(1, 11),<br>
(2, 22),<br>
...<br>
))<br>
<br>
but then suppose someone says: "hey, folks do this a lot, let's make<br>
it more convenient" and introduce a curly braces notation, and suppose<br>
it allows overwriting, like it does now.<br>
<br>
The new notation exists *exclusively* to make it easier to type and<br>
read dictionaries in the code---by a human. Except that with these<br>
semantics it makes it impossible to detect duplicate key errors, which<br>
the vast majority of users would prefer to notice (a bold and unproven<br>
statement, but a reasonable guess).</blockquote></div><div><br></div><div>I'm part of the minority(?) that doesn't care. I hope that helps adjust your odds ratio for that guess.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What's worse, people don't<br>
realize the problem until they have many large dict displays, and many<br>
bugs. So they feel annoyed and betrayed.<br>
<br>
Suppose instead that the new notation does NOT allow overwriting. If<br>
folks rely on the overwrite semantics, in either human-written or<br>
machine-generated code, they will immediately notice the problem and<br>
use dict(), with very little inconvenience to code generators. (And<br>
some to the humans, but remember, they are a tiny minority :)<br></blockquote></div><div><br></div><div>Even a tiny minority of the Python community might be thousands of people.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The strict semantics are maybe marginally harder to explain, and maybe<br>
marginally harder to implement, but neither should be a show-stopper.<br>
<br>
However, that's not where we are. There is the legacy code issue, and<br>
the legacy mindset. I don't know how to evaluate these issues, and I<br>
don't even know how much experience the community has with<br>
backward-incompatible changes.</blockquote></div><div><br></div><div>Well, there's that transition from 2 to 3. You do that a few times and you get a reputation for instability.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> So, while I am fairly positive that it<br>
would have been a better choice to start with, I have no idea whether,<br>
when, and how this proposal should have any effect.<br>
<br>
P.S. The issue of detecting duplicate keys at parse time is<br>
completely separate and it was my mistake to focus on it first.<br>
<br>
P.P.S. The issue of whether a set display should allow duplicate<br>
elements is less important, since allowing them does not have<br>
destructive consequences.<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>