[Python-ideas] Dict joining using + and +=

[Steven D'Aprano]

On Mon, Mar 04, 2019 at 10:18:13PM -0800, Amber Yust wrote:

> Adding the + operator for dictionaries feels like it would be a mistake in
> that it offers at most sugar-y benefits, but introduces the significant
> drawback of making it easier to introduced unintended errors.

What sort of errors?

I know that some (mis-)features are "bug magnets" that encourage people 
to write buggy code, but I don't see how this proposal is worse than 
dict.update().

In one way it is better, since D + E returns a new dict, instead of 
over-writing the data in D. Ask any functional programmer, and they'll 
tell you that we should avoid side-effects.


> This would be
> the first instance of "addition" where the result can potentially
> lose/overwrite data (lists and strings both preserve the full extent of
> each operand; Counters include the full value from each operand, etc).

I don't see why this is relevant to addition. It doesn't even apply to 
numeric addition! If I give you the result of an addition:

    101

say, you can't tell what the operands were. And that's not even getting 
into the intricicies of floating point addition, which can violate 
associativity

    ``(a + b) + c`` is not necessarily equal to ``a + (b + c)``

and distributivity:

    ``x*(a + b)`` is not necessarily equal to ``x*a + x*b``


even for well-behaved, numeric floats (not NANs or INFs).


> Combining dictionaries is fundamentally an operation that requires more
> than one piece of information, because there's no single well-defined way
> to combine a pair of them. 

Indeed, But some ways are more useful than others.


> Off the top of my head, I can think of at least
> 2 different common options (replacement aka .update(), combination of
> values a la Counter). Neither of these is really a more valid "addition" of
> dictionaries.

That's why we have subclasses and operator overloading :-)

By far the most commonly requested behaviour for this is copy-and- 
update (or merge, if you prefer). But subclasses are free to define it 
as they will, including:

- add values, as Counter already does;
- raise an exception if there is a duplicate key;
- "first seen wins"

or anything else.



-- 
Steven