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?

-CHB







On Mon, Jun 1, 2020 at 2:22 PM Alex Hall <alex.moj...@gmail.com> wrote:

> On Mon, Jun 1, 2020 at 8:50 PM Brandt Bucher <brandtbuc...@gmail.com>
> 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](
> https://mail.python.org/archives/list/python-ideas@python.org/message/WX7PNKTOX2RIYKA4G2OC7RD4HHRLUSBA/)
> 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 -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/OP5IWIBGDTQ2DALLA52Q2C7ARUUHYIT7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FTRYONGSD4UARRVN2XHZ2VEXIQLVQAHT/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to