<div dir="ltr">Honestly I would rather withdraw the subtraction operators than reopen the discussion about making dict more like set.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 4, 2019 at 12:33 PM Neil Girdhar <<a href="mailto:mistersheik@gmail.com">mistersheik@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 4, 2019 at 3:22 PM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br>
><br>
> On Mon, Mar 4, 2019 at 12:12 PM Neil Girdhar <<a href="mailto:mistersheik@gmail.com" target="_blank">mistersheik@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Mar 4, 2019 at 2:26 PM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br>
>> ><br>
>> > * Dicts are not like sets because the ordering operators (<, <=, >, >=) are not defined on dicts, but they implement subset comparisons for sets. I think this is another argument pleading against | as the operator to combine two dicts.<br>
>> ><br>
>><br>
>> I feel like dict should be treated like sets with the |, &, and -<br>
>> operators since in mathematics a mapping is sometimes represented as a<br>
>> set of pairs with unique first elements.  Therefore, I think the set<br>
>> metaphor is stronger.<br>
><br>
><br>
> That ship has long sailed.<br>
<br>
Maybe, but reading through the various replies, it seems that if you<br>
are adding "-" to be analogous to set difference, then the combination<br>
operator should be analogous to set union "|".  And it also opens an<br>
opportunity to add set intersection "&".  After all, how do you filter<br>
a dictionary to a set of keys?<br>
<br>
>> d = {'some': 5, 'extra': 10, 'things': 55}<br>
>> d &= {'some', 'allowed', 'options'}<br>
>> d<br>
{'some': 5}<br>
<br>
>><br>
>> > * Regarding how to construct the new set in __add__, I now think this should be done like this:<br>
>> ><br>
>> > class dict:<br>
>> >     <other methods><br>
>> >     def __add__(self, other):<br>
>> >         <checks that other makes sense, else return NotImplemented><br>
>> >         new = self.copy()  # A subclass may or may not choose to override<br>
>> >         new.update(other)<br>
>> >         return new<br>
>><br>
>> I like that, but it would be inefficient to do that for __sub__ since<br>
>> it would create elements that it might later delete.<br>
>><br>
>> def __sub__(self, other):<br>
>>  new = self.copy()<br>
>>  for k in other:<br>
>>   del new[k]<br>
>> return new<br>
>><br>
>> is less efficient than<br>
>><br>
>> def __sub__(self, other):<br>
>>  return type(self)({k: v for k, v in self.items() if k not in other})<br>
>><br>
>> when copying v is expensive.  Also, users would probably not expect<br>
>> values that don't end up being returned to be copied.<br>
><br>
><br>
> No, the values won't be copied -- it is a shallow copy that only increfs the keys and values.<br>
<br>
Oh right, good point.  Then your way is better since it would preserve<br>
any other data stored by the dict subclass.<br>
><br>
> --<br>
> --Guido van Rossum (<a href="http://python.org/~guido" rel="noreferrer" target="_blank">python.org/~guido</a>)<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>