[Python-Dev] PySequence_Concat for dicts (original) (raw)

Raymond Hettinger python at rcn.com
Sun Jan 13 00:32:31 CET 2008

[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

More information about the Python-Dev mailing list