[Python-Dev] PEP 544: Protocols - second round (original) (raw)
Guido van Rossum guido at python.org
Fri May 26 16:51:50 EDT 2017
- Previous message (by thread): [Python-Dev] PEP 544: Protocols - second round
- Next message (by thread): [Python-Dev] PEP 544: Protocols - second round
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, May 25, 2017 at 7:19 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
Given the abstract, I'd suggest "Structural Subtyping" as a suitable title for the PEP.
Maybe even "Structural Subtyping (a.k.a. Duck Typing)"
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.
Agreed.
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.
Yes. Imports don't enter the matter. (Things get tied together at the call sites.) @Ivan: if there isn't an example that makes this clear we should add one.
-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170526/79eef781/attachment.html>
- Previous message (by thread): [Python-Dev] PEP 544: Protocols - second round
- Next message (by thread): [Python-Dev] PEP 544: Protocols - second round
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]