-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Extending a Protocol leads to unsafe behavior #8005
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
Comments
The real source of unsafety here is #2350. A quick fix in the context of protocols (assuming we are not fixing the root cause soon) is to treat methods with empty bodies as implicitly abstract. |
FWIW, |
See python#8005 for the motivation. There are some subtleties to this; for one, we can't apply the rule to type stubs, because they never have a function body. And of course, if the return type is `None` or `Any`, then an empty function is completely valid.
Closes python#8005 Closes python#8926 Methods in Protocols are considered abstract if they have an empty function body, have a return type that is not compatible with `None`, and are not in a stub file.
If you annotate |
Closes python#8005 Closes python#8926 Methods in Protocols are considered abstract if they have an empty function body, have a return type that is not compatible with `None`, and are not in a stub file.
Closes python#8005 Closes python#8926 Methods in Protocols are considered abstract if they have an empty function body, have a return type that is not compatible with `None`, and are not in a stub file.
Closes python#8005 Closes python#8926 Methods in Protocols are considered abstract if they have an empty function body, have a return type that is not compatible with `None`, and are not in a stub file.
Are you reporting a bug, or opening a feature request?
bug
Please insert below the code you are checking with mypy, or a mock-up repro if the source is private. We would appreciate if you try to simplify your case to a minimal repro.
What is the actual behavior/output?
A().foo() + 5
crashes at runtime withTypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
B
is correctly type checked and rejected.What is the behavior/output you expect?
According to https://mypy.readthedocs.io/en/latest/protocols.html#defining-subprotocols-and-subclassing-protocols, "Explicitly including a protocol as a base class ... forces mypy to verify that your class implementation is actually compatible with the protocol."
I would expect extending a Protocol to be similar to implementing an interface in Java.
In this particular example, mypy should ideally detect that
A
does not fill in the stub method fromP
, like it does forB
. Alternatively, if that is not possible, perhaps extending a protocol should not be allowed.What are the versions of mypy and Python you are using? Do you see the same issue after installing mypy from Git master?
Python 3.8.0
mypy 0.750+dev.d9dea5f3ad30bb449e4167b3e8476684ded0482e
What are the mypy flags you are using? (For example --strict-optional)
mypy --strict test.py
The text was updated successfully, but these errors were encountered: