<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 March 2017 at 22:11, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'm a big fan of this. I really want structural subtyping for <a href="http://github.com/google/pytype" target="_blank">http://github.com/google/<wbr>pytype</a>.<br><div><br></div></div></blockquote><div><br></div><div>I am glad you like it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Mon, Mar 20, 2017 at 5:00 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Explicitly declaring implementation<br></div><div>------------------------------<wbr>-----<br><br>To explicitly declare that a certain class implements the given protocols,<br></div></div></blockquote><div><br></div></span><div>Why is this necessary? The whole point of ducktyping is that you *don't* have to declare what you implement.</div><div><br></div><div>I get that it looks convenient to have your protocol A also supply some of the methods you'd expect classes of type A to have. But completing an implementation in that way should be done explicitly (via including a utility class or using a decorator like functools.total_ordering), not as side-effect of an (unnecessary) protocol declaration.</div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">I would put the question backwards: do we need to *prohibit* explicit subclassing?<br></div><div class="gmail_extra">I think we shouldn't. Mostly for two reasons:<br><br></div><div class="gmail_extra">1. Backward compatibility: People are already using ABCs, including generic ABCs from typing module.<br>If we prohibit explicit subclassing of these ABCs, then quite a lot of code will break.<br><br></div><div class="gmail_extra">2. Convenience: There are existing protocol-like ABCs (that will be turned into protocols) that have many<br>useful "mix-in" (non-abstract) methods. For example in case of Sequence one<br></div><div class="gmail_extra">only needs to implement __getitem__ and __len__ in an explicit subclass, and one gets<br>__iter__, __contains__, __reversed__, index, and count for free. Another example is Mapping,<br>one needs to implement only __getitem__, __len__, and __iter__, and one gets __contains__, keys,<br>items, values, get, __eq__, and __ne__ for free.<br><br></div><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 class="gmail_extra"><br>--<br></div><div class="gmail_extra">Ivan<br><br><br></div></div>