Should `collections.abc.MutableMapping` implement `__ior__` as a mixin?

Ideas
1

dict implements the |= operator as follows:

d |= other

Update the dictionary d with keys and values from other, which may be either a mapping or an iterable of key/value pairs. The values of other take priority when d and other share keys.

This appears to be equivalent to calling d.update(other) with no keywords:

update(**kwargs )

update(mapping, /, **kwargs )
update(iterable, /, **kwargs )

Update the dictionary with the key/value pairs from mapping or iterable and kwargs, overwriting existing keys. Return None.

update() accepts either another object with a keys() method (in which case __getitem__() is called with every key returned from the method) or an iterable of key/value pairs (as tuples or other iterables of length two). If keyword arguments are specified, the dictionary is then updated with those key/value pairs: d.update(red=1, blue=2).

However, collections.abc.MutableMapping does not implement __ior__() as a mixin method despite implementing MutableMapping.update().

Was this simply an oversight in the implementation of MutableMapping, or was there a reason a definition for __ior__() was omitted? If the former, should MutableMapping implement __ior__() as follows?

def __ior__(self, value):
    self.update(value)
2

Whether an oversight or not (and I would lean toward not), it’s not possible to add to the collections abcs without it being a breaking change, as these describe expectations of interfaces.

There’s a gigantic comment at the top of the file in which these are implemented which explains the rationale behind that in more detail.

6 Likes
3

Additionally, if you go back to PEP 584, it notes this issue, alongside the fact that mapping | mapping can’t be done generally since there isn’t a generic way to copy the mapping.

5 Likes
4

I have definitely made the mistake of confusing the concrete implementations of the abstracts with the abc definitions before.

It does take a second to remember that the abcs aren’t defining the contracts you get with list, tuple, set, and dict, but instead defining the minimum viable interface for something that behaves like one of those concrete classes.

Mapping makes no guarantee of key order, even though dict (now) does. It also doesn’t handle keys() the same way for example.

5

It would be a breaking change only if an abstract method were added, which is not what this proposal is suggesting.

6

Any addition, abstract or not, changes what types qualify as meeting that type, and the collection abcs also serve a purpose in structural typing for python’s type system.

See how isinstance works for these types, described under points 2 and 3 collections.abc — Abstract Base Classes for Containers — Python 3.14.3 documentation

As well as this section in the actual source:

4 Likes
7

I don’t think the rule is correct. For example, the following code would not break any typing check if Sequence were to add a new mixin method:

from collections.abc import Sequence

class S(Sequence):
    def __getitem__(self, index):
        return 0
    def __len__(self):
        return 0

def f(s: Sequence):
    ...

f(S()) # passes typing check
8

Not every Sequence inherits from Sequence. Part of the point of ABCs is that they can be recognized by the methods alone, without explicitly inheriting. It’s a breaking change to add methods.

4 Likes
9

Ah I stand corrected. To be more precise it’s more of the point of a protocol rather than of the point of an ABC, even though protocols are implemented as ABCs.

10

Indeed. The upshot is the same since the ABCs are locked in with the protocols they’re declaring support for.

1 Like
11

Adding |= to MutableMapping (or a copy method to Mapping) would create compatibility issues for virtual subclasses.

That makes sense. I hadn’t considered the virtual subclasses aspect. Agreed that this would be a breaking change.