<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 6, 2019 at 11:52 AM Rhodri James <<a href="mailto:rhodri@kynesim.co.uk">rhodri@kynesim.co.uk</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 06/03/2019 10:29, Ka-Ping Yee wrote:<br>
> len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the +<br>
> operator is nonsense.<br>
<br>
I'm sorry, but you're going to have to justify why this identity is <br>
important.  Making assumptions about length where any dictionary <br>
manipulations are concerned seems unwise to me, which makes a nonsense <br>
of your claim that this is nonsense :-)<br></blockquote><div><br></div><div>It's not "nonsense" per se. If we were inventing programming languages in a vacuum, you could say + can mean "arbitrary combination operator" and it would be fine. But we're not in a vacuum; every major language that uses + with general purpose containers uses it to mean element-wise addition or concatenation, not just "merge". Concatenation is what imposes that identity (and all the others people are defending, like no loss of input values); you're taking a sequence of things, and shoving another sequence of things on the end of it, preserving order and all values.</div><div><br></div><div>The argument here isn't that you *can't* make + do arbitrary merges that don't adhere to these semantics. It's that adding yet a third meaning to + (and it is a third meaning; it has no precedent in any existing type in Python, nor in any other major language; even in the minor languages that allow it, they use + for sets as well, so Python using + is making Python itself internally inconsistent with the operators used for set), for limited benefit.<br></div><div><br></div><div>- Josh Rosenberg<br></div></div></div>