<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2019 at 3:50 PM Josh Rosenberg <<a href="mailto:shadowranger%2Bpythonideas@gmail.com">shadowranger+pythonideas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2019 at 11:16 PM Steven D'Aprano <<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Mar 03, 2019 at 09:28:30PM -0500, James Lu wrote:<br>
<br>
> I propose that the + sign merge two python dictionaries such that if <br>
> there are conflicting keys, a KeyError is thrown.<br>
<br>
This proposal is for a simple, operator-based equivalent to <br>
dict.update() which returns a new dict. dict.update has existed since <br>
Python 1.5 (something like a quarter of a century!) and never grown a <br>
"unique keys" version.<br>
<br>
I don't recall even seeing a request for such a feature. If such a <br>
unique keys version is useful, I don't expect it will be useful often.<br></blockquote><div><br></div><div>I have one argument in favor of such a feature: It preserves concatenation semantics. + means one of two things in all code I've ever seen (Python or otherwise):</div><div><br></div><div>1. Numeric addition (including element-wise numeric addition as in Counter and numpy arrays)</div><div>2. Concatenation (where the result preserves all elements, in order, including, among other guarantees, that len(seq1) + len(seq2) == len(seq1 + seq2))</div><div><br></div><div>dict addition that didn't reject non-unique keys wouldn't fit *either* pattern; the main proposal (making it equivalent to left.copy(), followed by .update(right)) would have the left hand side would win on ordering, the right hand side on values, and wouldn't preserve the length invariant of concatenation. At least when repeated keys are rejected, most concatenation invariants are preserved; order is all of the left elements followed by all of the right, and no elements are lost. <br></div></div></div></blockquote><div><br></div><div>I must by now have seen dozens of post complaining about this aspect of the proposal. I think this is just making up rules (e.g. "+ never loses information") to deal with an aspect of the design where a *choice* must be made. This may reflect the Zen of Python's "In the face of ambiguity, refuse the temptation to guess." But really, that's a pretty silly rule (truly, they aren't all winners). Good interface design constantly makes choices in ambiguous situations, because the alternative is constantly asking, and that's just annoying.</div><div><br></div><div>We have a plethora of examples (in fact, almost all alternatives considered) of situations related to dict merging where a choice is made between conflicting values for a key, and it's always the value further to the right that wins: from d[k] = v (which overrides the value when k is already in the dict) to d1.update(d2) (which lets the values in d2 win), including the much lauded {**d1, **d2} and even plain {'a': 1, 'a': 2} has a well-defined meaning where the latter value wins.</div><div><br></div><div>As to why raising is worse: First, none of the other situations I listed above raises for conflicts. Second, there's  the experience of str+unicode in Python 2, which raises if the str argument contains any non-ASCII bytes. In fact, we disliked it so much that we changed the language incompatibly to deal with it.<br></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div></div></div>