Skip to content

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

Closed
jingw opened this issue Nov 23, 2019 · 3 comments · Fixed by #12118
Closed

Extending a Protocol leads to unsafe behavior #8005

jingw opened this issue Nov 23, 2019 · 3 comments · Fixed by #12118

Comments

@jingw
Copy link
Contributor

jingw commented Nov 23, 2019

  • 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.

from typing import Protocol

class P(Protocol):
    def foo(self) -> int: ...

class A(P):  # mypy does not flag this
    pass

class B:
    pass

test: P = A()  # mypy does not flag this
test = B()  # mypy flags this

print(A().foo() + 5)  # both error at runtime
print(B().foo() + 5)
  • What is the actual behavior/output?
    A().foo() + 5 crashes at runtime with TypeError: 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 from P, like it does for B. 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

@ilevkivskyi
Copy link
Member

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.

@tmke8
Copy link
Contributor

tmke8 commented Jan 23, 2022

FWIW, pyright now handles this correctly as of version 1.1.213. (The relevant commit: microsoft/pyright@44c98fe)

tmke8 added a commit to tmke8/mypy that referenced this issue Jan 24, 2022
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.
tmke8 added a commit to tmke8/mypy that referenced this issue Feb 3, 2022
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.
@nickgaya
Copy link

nickgaya commented Feb 4, 2022

If you annotate P.foo with @abstractmethod then MyPy will behave as expected. I recommend closing this bug as invalid.

tmke8 added a commit to tmke8/mypy that referenced this issue Feb 10, 2022
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.
tmke8 added a commit to tmke8/mypy that referenced this issue Feb 23, 2022
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.
tmke8 added a commit to tmke8/mypy that referenced this issue Jul 29, 2022
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment