<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 28, 2017 at 8:27 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 28 May 2017 at 16:13, Kevin Conway <span dir="ltr"><<a href="mailto:kevinjacobconway@gmail.com" target="_blank">kevinjacobconway@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"><span>> <span style="color:rgb(33,33,33)">Some of the possible options for the title are</span></span><div><span style="color:rgb(33,33,33)">It seems like you're talking about something most other languages would refer to as "Interfaces". What is unique about this proposal that would call for not using the industry standard language?</span></div><span></span></div></blockquote><div><br></div></span><div>Well, I would say there is no "industry standard language" about structural subtyping. There are interfaces, protocols,<br>traits, mixins, typeclasses, roles, and probably some other terms I am not aware of - all with subtly different semantics<br>in different languages. There are several reasons why we use term protocol and not interface.<br>Two important reasons for me are:<br></div><div>* The term protocol is already de-facto standard in Python for things like sequence protocol, iterator protocol,<br>  descriptor protocol, etc.<br></div><div>* Protocols are very different from Java interfaces in one important aspect: they don't require explicit<br>  declaration of implementation, they are mainly oriented on duck-typing.<br></div><div>Maybe we need to add a short section to rejected ideas?<br></div></div></div></div></blockquote><div><br></div><div>If you feel like it.<br><br></div><div>Regarding the title, I'd like to keep the word Protocol in the title too, so I'd go with "Protocols: Structural subtyping (duck typing)" -- hope that's not too long to fit in a PEP title field.<br></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"><div class="gmail_quote"><div></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div><span style="color:rgb(33,33,33)"></span></div><div><span style="color:rgb(33,33,33)">> </span><span style="color:rgb(33,33,33)">Type-hints should not have runtime semantics, beyond those that </span><span style="color:rgb(33,33,33)">they have as classes</span></div></span><span><div><span style="color:rgb(33,33,33)">> </span><span class="m_568895367229424800m_4555750317579146067inbox-inbox-Apple-converted-space" style="color:rgb(33,33,33)"> </span><span style="color:rgb(33,33,33)">lots of code uses isinstance(obj, collections.abc.Iterable) and similar checks with other ABCs</span></div></span><div><span style="color:rgb(33,33,33)">Having interfaces defined as something extended from abc doesn't necessitate their use at runtime, but it does open up a great deal of options for those of us who want to do so. I've been leveraging abc for a few years now to implement a lightweight version of what this PEP is attempting to achieve</span><br></div></div></blockquote></span></div><br></div><div class="gmail_extra">IIUC this is not the main goal of the PEP, the main goal is to provide support/standard for _static_ structural subtyping.<br></div><div class="gmail_extra">Possibility to use protocols in runtime context is rather a minor bonus that exists mostly to provide a seamless transition<br></div><div class="gmail_extra">for projects that already use ABCs.<br></div></div></blockquote></div><br></div><div class="gmail_extra">Is something like this already in the PEP? It deserves attention in one of the earlier sections.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>