Home Original page

[Python-Dev] PEP 544: Protocols - second round

Ivan Levkivskyi levkivskyi at gmail.com
Mon May 29 06:41:42 EDT 2017 
On 28 May 2017 at 19:40, Guido van Rossum <guido at python.org> wrote:

> On Sun, May 28, 2017 at 8:27 AM, Ivan Levkivskyi <levkivskyi at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170529/45a445e8/attachment.html>
More information about the Python-Dev mailing list