On Wed, Mar 6, 2019 at 11:52 AM Rhodri James <rho...@kynesim.co.uk> wrote:
> On 06/03/2019 10:29, Ka-Ping Yee wrote: > > len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the + > > operator is nonsense. > > I'm sorry, but you're going to have to justify why this identity is > important. Making assumptions about length where any dictionary > manipulations are concerned seems unwise to me, which makes a nonsense > of your claim that this is nonsense :-) > 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. 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. - Josh Rosenberg
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
