<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 20, 2017 at 2:42 PM, Ivan Levkivskyi <span dir="ltr"><<a href="mailto:levkivskyi@gmail.com" target="_blank">levkivskyi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">1. Backward compatibility: People are already using ABCs, including generic ABCs from typing module.<br></div></div><div class="gmail_extra">If we prohibit explicit subclassing of these ABCs, then quite a lot of code will break.<br></div></div></blockquote><div><br></div><div>Fair enough. Backwards compatibility is a valid point, and both abc.py and typing.py have classes that lend itself to becoming protocols.</div><div><br></div><div>The one thing that isn't clear to me is how type checkers will distinguish between </div><div>1.) Protocol methods in A that need to implemented in B so that B is considered a structural subclass of A.</div><div>2.) Extra methods you get for free when you explicitly inherit from A.</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">If you think it makes sense to add a note that implicit subtyping is preferred (especially for user defined protocols),<br></div><div class="gmail_extra">then this certainly could be done.<br></div></div></blockquote><div><br></div><div>Yes, I believe it would be good to mention that.</div></div></div></div>