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

[Nick Coghlan]

On 25 May 2017 at 21:26, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 24 May 2017 23:31:47 +0200
> Ivan Levkivskyi <levkivskyi at gmail.com> wrote:
>
>> Hi all,
>>
>> After collecting suggestions in the previous discussion on python-dev
>> https://mail.python.org/pipermail/python-dev/2017-March/thread.html#147629
>> and playing with implementation, here is an updated version of PEP 544.
>>
>> --
>> Ivan
>>
>>
>> A link for those who don't like reading long e-mails:
>> https://www.python.org/dev/peps/pep-0544/
>>
>> =========================
>>
>> PEP: 544
>> Title: Protocols
>
> Can you give this PEP a more explicit title? "Protocols" sound like
> network protocols to me.

Especially given the existing use of the term in an asyncio context:
https://www.python.org/dev/peps/pep-3156/#transports-and-protocols

Given the abstract, I'd suggest "Structural Subtyping" as a suitable
title for the PEP.

That said, I think it's fine to use "protocol" throughout the rest of
the PEP as is currently the case - object protocols and network
protocols are clearly different things, it's just the bare word
"Protocols" appearing as a PEP title in the PEP index with no other
context that's potentially confusing.

I'm +1 on the general idea of the PEP, and only have one question
regarding the specifics. Given:

    import typing

    class MyContainer:
        def __len__(self) -> int:
            ...
        def close(self) -> None:
            ...

Would that be enough for a static typechecker to consider MyContainer
a structural subtype of both typing.Sized and SupportsClose from the
PEP, even though neither is imported explicitly into the module? I'm
assuming the answer is "Yes", but I didn't see it explicitly stated
anywhere.

Cheers,
Nick.



-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia