<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 March 2017 at 17:09, Matthias Kramm <span dir="ltr"><<a href="mailto:kramm@google.com" target="_blank">kramm@google.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"><br><div class="gmail_quote"><span class=""></span>The one thing that isn't clear to me is how type checkers will distinguish between <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></div></blockquote><div><br></div><div>An implicit subtype should implement all methods, so that yes, in this case __eq__ should be implemented for Mapping.<br></div><div><br>There was an idea to make some methods "non-protocol" (i.e. not necessary to implement), but it was rejected,<br>since this complicates things. Briefly, consider this function:<br><br></div><div>def fun(m: Mapping):<br></div><div>    m.keys()<br></div><div><br></div><div>The question is should this be an error? I think most people would expect this to be valid.<br></div><div>The same applies to most other methods in Mapping, people expect that<br></div><div>they are provided my Mapping. Therefore, to be on the safe side, we need<br>to require these methods to be implemented. If you look at definitions in collections.abc,<br></div><div>there are very few methods that could be considered "non-protocol". Therefore, it was decided<br></div><div>to not introduce "non-protocol" methods.<br><br></div><div>There is only one downside for this: it will require some boilerplate for implicit subtypes of Mapping etc.<br></div><div>But, this applies to few "built-in" protocols (like Mapping and Sequence) and people already subclass them.<br></div><div>Also, such style will be discouraged for user defined protocols. It will be recommended to create compact<br></div><div>protocols and combine them. (This was discussed, but it looks like we forgot to add an explicit statement about this.)<br></div><div><br></div><div>I will add a section on non-protocol methods to rejected/postponed ideas.<br><br>--<br></div><div>Ivan<br><br><br></div></div></div></div>