TL; DR: In this particular case, I don't see much backward compatibility, so yes, let's add them.

I've been thinking about the concept of adding methods (mixin or virtual) to ABCs in the context of the "views on sequences" conversation recently on this list.

In that context, we (or I, anyway :-) ) decided that it's potentially very disruptive to add a method (as opposed to a new protocol, via a dunder) -- because only the dunder "namespace" is reserved. It that case, there was a concrete example: a `.view` method added as a mixin to the Sequence ABC would be an obvious way to support the use case at hand, but it would then conflict with any Sequence-like (either registered with the ABC, or simply duck typed) that had a `.view` method with a different meaning -- and numpy arrays DO have a .view method with a different meaning -- so a lot of code could break. We could come up with a more obscure name, but then it would be less intuitive, and any name *could* conflict with something somewhere.

What all that means is that's a very big deal to add a new non-dunder name to an existing ABC, and we will probably rarely, or never do it.

BUT: This *may* be a different case -- the Set ABC (and set duck-typing) is probably far less used than for Sequences. ANd while the proposed methods are not part of the Set ABC at this point, they ARE part of the build in set object. And historically at least, people informally duck typed as often, or more often, than they subclassed from or registered with ABCs anyway.

All that is to say that there are no set-like objects in the standard library that have these names with a different meaning, and probably VERY few, of any third party set-like classes that have these names with different meanings as well.

So it would not likely break much at all if they were added. (and I'm still confused why they aren't there in the firs place, the PEP doesn't seem very clear about it)

And even if they are not added to the ABC, they could still be added to the other set-like objects in the standard library -- are there any other than the dict views?


On Mon, Jun 1, 2020 at 2:22 PM Alex Hall <> wrote:
On Mon, Jun 1, 2020 at 8:50 PM Brandt Bucher <> wrote:
> These would be mixin methods, not abstract. Set already implements the various operators based on the abstract methods, it could easily add more mixin methods which would delegate to the operators. Classes which override the operators with more efficient versions would automatically get efficient aliases for free.

This same idea came up when we added `|` / `|=` to `dict` in 3.8. The reason we couldn't safely add those to `Mapping`/`MutableMapping` is that it could break compatibility for virtual subclasses that have been `register`-ed, and don't actually inherit from the ABC.

The problem is the same here.

OK, I wasn't on this list then, and I haven't found much while searching. I found a brief mention of the problem [here]( without much explanation of why it might be a problem, and a reply saying that it's not. So I may ask some questions that have been resolved already.

What do you mean by 'break compatibility'? Registering a virtual subclass doesn't enforce that any methods are implemented, not even the abstract ones.

Are virtual subclasses required to implement all the mixin methods? I thought the mixin methods were just a nice conveniece, not a contract.
Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython