-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protocols #417
Protocols #417
Conversation
Something strange happened here (or maybe the comment was deleted), but here is an interesting note to make: because of how @runtime
class P(Protocol):
x: int
class N(NamedTuple):
x: int
assert issubclass(N, P) # OK |
I left a comment that I realized was completely incorrect so I deleted it |
I will soon make another PR that will add (simplified) I will keep this PR open (and update depending on the outcome of experiments with |
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 |
This was superseded by #649 |
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__
incollections.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:
Then I propose the following subclass check results:
The first one is probably obvious, the second one returns
False
to make this safe:The last one although safe since one cannot instantiate protocols, and this is probably what one would expect.
Attn: @JukkaL @ambv @gvanrossum