[Python-Dev] PySequence_Concat for dicts

[Jared Flatow]

On Jan 12, 2008, at 5:32 PM, Raymond Hettinger wrote:
> Not natural, just inefficient and cute.  Also, there was no answer
> to the question about use cases.

Fair enough. I will present some use cases below.

> 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.

What about the patch I initially presented (and which you originally  
dealt with)?

http://mail.python.org/pipermail/patches/2004-March/014323.html

It seems the original request just never discussed the issue of  
duplicate keys (for some odd reason).

> 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.


It was foolish of me to make those comments, you're right, and I  
should have known better. Guido has made it clear that the correct  
interpretation is that the keys of a dict form a set, which gets rid  
of any ambiguity. The set operators are most appropriate, though I am  
not exactly clear on whether this is already going to be implemented  
in a future version of Python, or if its just that noone will object  
if it appears in a future version. If it is the latter, I would still  
like to take a stab at implementing this as a first contribution.  
Would you please advise?

> 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.

I agree operators are not the solution to all problems (need they be  
the solution to any?). My argument about + for lists was merely based  
on the precedent it established for sometimes sacrificing efficiency  
for clarity. Sometimes you may not want to alter the original lists  
(just as sometimes you may not want to alter the original dicts), but  
even when it does not matter if you do, you might still write:

def prepend_with_a_b(list_a):
	return ['a', 'b'] + list_a

instead of

def prepend_with_a_b(list_a):
	list_b = ['a', 'b']
	list_b.extend(list_a)
	return list_b

Even though I suspect the latter will often be more efficient. The |  
operation for dict will not do anything that you could not otherwise  
do with update. I suspect most usage will be to simplify code as  
above. As for use cases when you actually want a new dict, I am  
guessing you do not want to know specifically why I don't want to  
alter dicts, but a more general use case, in which event the most  
generalized example is any case where you simply do not want to  
modify the original dicts.

Since it seems that you might not actually need convincing that  
having the 4 set operations supported would be a reasonable thing to  
do, I will stop here for now.

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

I suppose I should be glad for that? I might have thought you to put  
that to its discredit. Anyhow, I am not sure if we are now in  
agreement or not, but if so would you please advise on how to proceed?

jared