On 28 May 2017 at 19:40, Guido van Rossum <gu...@python.org> wrote: > On Sun, May 28, 2017 at 8:27 AM, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > [...]
> 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. > OK, this looks reasonable. > > > Type-hints should not have runtime semantics, beyond those that they >>> have as classes >>> > lots of code uses isinstance(obj, collections.abc.Iterable) and >>> similar checks with other ABCs >>> 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 >>> >> >> IIUC this is not the main goal of the PEP, the main goal is to provide >> support/standard for _static_ structural subtyping. >> Possibility to use protocols in runtime context is rather a minor bonus >> that exists mostly to provide a seamless transition >> for projects that already use ABCs. >> > > Is something like this already in the PEP? It deserves attention in one of > the earlier sections. > Yes, similar discussions appear in "Rationale and Goals", and "Existing approaches to structural subtyping". Maybe I need to polish the text there adding more focus on static typing. -- Ivan
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
