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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
