[Python-Dev] PySequence_Concat for dicts

[Raymond Hettinger]

[Raymond]
>>> When does it come-up that you want a third summed dict
>>> while keeping the two originals around unchanged?  Does
>>> it matter that the addition is non-commutative?  Would
>>> a + b + c produce an intermediate a/b combo and then
>>> another new object for a/b/c so that the entries in
>>> a get copied twice and memory usage has to hold a, b,
>>> a/b, c, and a/b/c in memory all at the same time?

[Jared]
> There is no way around it, this will be less efficient than the  
> inplace operation. If there were a precedent for calling a method  
> like update and returning itself instead of None, I would suggest  
> that, but since this is the way that has already been established for  
> lists, it seems a natural extension.

Not natural, just inefficient and cute.  Also, there was no answer
to the question about use cases.  AFAICT, this feature has never 
been requested.  The closest was a feature request for a
variant of update() that avoided overwrites when a duplicate
key was encountered -- Guido rejected that one a long time ago.

Your previous note suggests that there are alternative interpretations
of what the syntax could mean and that's not good a good thing.
That sort of ambiguity damages the language. It is not even
clear where the appropriate operators would be +-* or the
set operators &|^-.  How about we keep sets for set operations 
and dict for mapping operations and not foolishly conflate the two
just because we can.  The mapping API is central to the language.
Altering it should be approached with a great deal of care.

Also, the argument that we used + for lists so now we have
to do it for dicts is a weak one -- they are completely different animals.
Operators are not the solution to all problems.  In this case, we
don't even have a problem to be solved; there is just an urge
to hypergeneralize what was done for other datatypes where
it was appropriate.  The .update() method we have now is explicit, 
clear about its intent, and efficient.

IMO, the only thing this proposal has going for it is that it is cute.


Raymond