While working through my implementation, I've come across a couple of inconsistencies with the current proposal:
> The merge operator will have the same relationship to the
dict.update method as the list concatenation operator has to
list.extend, with dict difference being defined analogously.
I like this premise. += for lists *behaves* like extend, and += for dicts *behaves* like update.
However, later in the PEP it says:
> Augmented assignment will just call the update method. This is
analogous to the way list += calls the extend method, which
accepts any iterable, not just lists.
In your Python implementation samples from the PEP, dict subclasses will behave differently from how list subclasses do. List subclasses, without overrides, return *list* objects for bare "+" operations (and "+=" won't call an overridden "extend" method). So a more analogous pseudo-implementation (if that's what we seek) would look like:
def __add__(self, other):
if isinstance(other, dict):
new = dict.copy(self)
dict.update(new, other)
return new
return NotImplemented
def __radd__(self, other):
if isinstance(other, dict):
new = dict.copy(other)
dict.update(other, self)
return new
return NotImplemented
def __iadd__(self, other):
if isinstance(other, dict):
dict.update(self, other)
return self
return NotImplemented
This is what my C looks like right now. We can choose to update these semantics to be "nicer" to subclasses, but I don't see any precedent for it (lists, sets, strings, etc.).
Brandt