<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 21 Mar 2017 at 09:17 Matthias Kramm via Python-Dev <<a href="mailto:python-dev@python.org">python-dev@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Mar 20, 2017 at 2:42 PM, Ivan Levkivskyi <span dir="ltr" class="gmail_msg"><<a href="mailto:levkivskyi@gmail.com" class="gmail_msg" target="_blank">levkivskyi@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">1. Backward compatibility: People are already using ABCs, including generic ABCs from typing module.<br class="gmail_msg"></div></div><div class="gmail_extra gmail_msg">If we prohibit explicit subclassing of these ABCs, then quite a lot of code will break.<br class="gmail_msg"></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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></div></div></blockquote><div><br></div><div>Another key point is that if you block subclassing then this stops being useful to anyone not using a type checker. While the idea of protocols is to support structural typing, there is nothing wrong with having nominal typing through ABCs help enforce the structural typing of a subclass at the same time. You could argue that if you want that you define the base ABC first and then have a class that literally does nothing but inherit from that base ABC and Protocol, but that's unnecessary duplication in an API to have the structural type and nominal type separate when we have a mechanism that can support both.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The one thing that isn't clear to me is how type checkers will distinguish between </div><div class="gmail_msg">1.) Protocol methods in A that need to implemented in B so that B is considered a structural subclass of A.</div><div class="gmail_msg">2.) Extra methods you get for free when you explicitly inherit from A.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg">If you think it makes sense to add a note that implicit subtyping is preferred (especially for user defined protocols),<br class="gmail_msg"></div><div class="gmail_extra gmail_msg">then this certainly could be done.<br class="gmail_msg"></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Yes, I believe it would be good to mention that.</div></div></div></div></blockquote><div><br></div><div>I don't think it needs to be explicitly discouraged if you want to make sure you implement the abstract methods (ABCs are useful for a reason). I do think it's fine, though, to make it very clear that whether you subclass or not makes absolutely no difference to tools validating the type soundness of the code.</div></div></div>