(original) (raw)

On Mon, Mar 20, 2017 at 2:42 PM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:

1\. Backward compatibility: People are already using ABCs, including generic ABCs from typing module.
If we prohibit explicit subclassing of these ABCs, then quite a lot of code will break.

Fair enough. Backwards compatibility is a valid point, and both abc.py and typing.py have classes that lend itself to becoming protocols.

The one thing that isn't clear to me is how type checkers will distinguish between

1.) Protocol methods in A that need to implemented in B so that B is considered a structural subclass of A.

2.) Extra methods you get for free when you explicitly inherit from A.

To provide a more concrete example: Since Mapping implements \_\_eq\_\_, do I also have to implement \_\_eq\_\_ if I want my class to be (structurally) compatible with Mapping?

If you think it makes sense to add a note that implicit subtyping is preferred (especially for user defined protocols),
then this certainly could be done.

Yes, I believe it would be good to mention that.