[Python-ideas] [Python-Dev] hello, new dict addition for new eve ?

[Nathan Schneider]

On Fri, Dec 30, 2011 at 2:37 PM, Bruce Leban <bruce at leapyear.org> wrote:
>
> On Fri, Dec 30, 2011 at 9:12 AM, Eric Snow <ericsnowcurrently at gmail.com>
> wrote:
>>
>> On Fri, Dec 30, 2011 at 10:02 AM, Guido van Rossum <guido at python.org>
>> 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/275bbd1acfa8d433/6c87b56021ca5f44


>
> 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 at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>