FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Protocols by ilevkivskyi · Pull Request #417 · python/typing · GitHub

/ typing Public

Protocols - #417

Closed
ilevkivskyi wants to merge 19 commits into
python:masterfrom
ilevkivskyi:protocols
Closed

Protocols#417
ilevkivskyi wants to merge 19 commits into
python:masterfrom
ilevkivskyi:protocols

Conversation

Copy link
Copy Markdown
Member

Fixes #11

This is a runtime implementation of protocols as per draft PEP 544. (The mypy counterpart is python/mypy#3132)

The implementation is straightforward (mostly I just made current version to behave more similar to __subclasshook__ in collections.abc and added support for __annotations__ in Python 3.6).
Nevertheless, I add a lot of tests. Some of them may look trivial, but previous experience with generics shows that it is better to have them.

There is probably only one corner case worth noting. Consider this situation with for variable annotations:

@runtime
class Proto(Protocol):
    attr: int
class OtherProto(Protocol):
    attr: int
class BadConcrete:
    attr: int
class GoodConcrete:
    attr = 1

Then I propose the following subclass check results:

issubclass(GoodConcrete, Proto) == True
issubclass(BadConcrete, Proto) == False # This is a bit questionable, maybe return True?
issubclass(OtherProto, Proto) == True

The first one is probably obvious, the second one returns False to make this safe:

if issubclass(BadConcrete, Proto):
    BadConcrete().attr

The last one although safe since one cannot instantiate protocols, and this is probably what one would expect.

Attn: @JukkaL @ambv @gvanrossum

ilevkivskyi commented May 10, 2017
edited
Loading

Copy link
Copy Markdown
Member Author

Something strange happened here (or maybe the comment was deleted), but here is an interesting note to make: because of how NamedTuple behaves at runtime (just making a collectios.namedtuple) it implements corresponding protocols already at the class level, for example:

@runtime
class P(Protocol):
    x: int
class N(NamedTuple):
    x: int

assert issubclass(N, P)  # OK

Daenyth commented May 10, 2017

Copy link
Copy Markdown

I left a comment that I realized was completely incorrect so I deleted it

ilevkivskyi mentioned this pull request May 16, 2017

Copy link
Copy Markdown
Member Author

I will soon make another PR that will add (simplified) Protocol to typing_extensions. We cannot add
all the functionality while Protocol will be in typing_extensions since several classes (like SupportsInt etc.) subclass _Protocol in typing, ideally they should subclass the new Protocol, this is however quite minor thing.

I will keep this PR open (and update depending on the outcome of experiments with typing_extensions).

ilevkivskyi added a commit to ilevkivskyi/typehinting that referenced this pull request Aug 19, 2017

Copy link
Copy Markdown
Member

So IIUC we should first merge #464 and defer this one until the PEP has been accepted, right?

Copy link
Copy Markdown
Member Author

So IIUC we should first merge #464 and defer this one until the PEP has been accepted, right?

Yes, also if there will be something we discover while playing with typing_extensions, I will update this PR accordingly (actually there are already few minor tweaks that I need to make here following the review of #464).

Copy link
Copy Markdown
Member Author

This was superseded by #649

ilevkivskyi deleted the protocols branch June 18, 2019 00:27
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Protocols (a.k.a. structural subtyping)

4 participants


Back | FazBrowse Home | New Git URL