On 28 May 2017 at 19:40, Guido van Rossum <guido@python.org> wrote:
On Sun, May 28, 2017 at 8:27 AM, Ivan Levkivskyi <levkivskyi@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
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
have as classes 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