On Fri, Dec 30, 2011 at 2:37 PM, Bruce Leban
On Fri, Dec 30, 2011 at 9:12 AM, Eric Snow
wrote: On Fri, Dec 30, 2011 at 10:02 AM, Guido van Rossum
wrote: What I meant is similar to set union on the keys, where if a key exists in both dicts, the value in the result is equal to one of the values in the operands (and if the value is the same for both operands, that value is also the result value).
+1
This is the one I was thinking of too.
-eric
My first thought on reading Julien's message was that {1:2} + {1:3} => {1:5} would be useful when doing reduction, There already is an operation that combines two dictionaries and does not combine values: update. Guido's version of + is a shorthand for:
def __add__(self, other): result = self.copy() return result.update(other)
The Counter class already supports this with the + operator. (It also supports element-wise max with the | operator.) Perhaps it would be useful to extend this support to dict, especially if there is a use case for element-wise string concatenation. As for a non-mutating alternative to update(): I have encountered a number of scenarios in which this is desirable. A previous suggestion [1] was to add a replace() method along these lines. But I think an operator would make it clearer which is the mutating vs. non-mutating one. Instead of +, I think << would be a better choice for this sort of modified concatenation/asymmetric union operation. For example, we can write: class Xdict(dict): def __lshift__(x, y): return Xdict(x.items() + y.items()) d = Xdict({'a': 9, 'b': 12}) d << {'a': 3, 'c': 8} # result: {'a': 3, 'b': 12, 'c': 8} d['a']==9 # True The rationale for <<: * __add__ (+) is quite common, and thus banning the addition of two dicts probably catches a lot of bugs. Moreover, when dict values are numeric, a user might expect element-wise addition (as in Counter). * __or__ (|) is classically a commutative operation, and is already overloaded by set and Counter. * Counter does not already overload <<, and thus could be extended to support the same behavior. * As far as I am aware, the only present use of << is for integer shifting, so this new idiom would not pose a conflict. Cheers, Nathan [1] http://groups.google.com/group/python-ideas/browse_thread/thread/275bbd1acfa...
Is saving one line of code be enough of a benefit?
I think dicts are complex enough that if new functionality is added, it would be better to use named methods which can have meaningful names and are easier look up in the documentation. Furthermore, methods are more flexible as this example shows:
def merge(self, other, merger=lambda x, y: x + y): """Merges another dictionary into this one, combining values.""" for k in other: if k in self: self[k] = merger(self[k], other[k]) else: self[k] = other[k]
--- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas