2017-05-25 7:19 GMT-07:00 Nick Coghlan <ncoghlan@gmail.com>:
On 25 May 2017 at 21:26, Antoine Pitrou <solipsis@pitrou.net> wrote:
> On Wed, 24 May 2017 23:31:47 +0200
> Ivan Levkivskyi <levkivskyi@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:

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

Yes, that should be the case. Specifically, if you pass a MyContainer object to a function whose argument is annotated as typing.Sized or SupportsClose, a type checker should accept that call.

Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia