-
Notifications
You must be signed in to change notification settings - Fork 234
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
super().__init__ doesn't work in explicit protocol subclasses #572
Comments
I have run in to this problem with @adisbladis, and he came up with this workaround: if not TYPE_CHECKING:
from typing import Generic
Protocol = Generic
def runtime_checkable(f):
return f
else:
from typing_extensions import Protocol, runtime_checkable I accidentally commented this on #561 at first, my apologies. |
Explicitly subclassed Protocols don't support super().__init__ ... but we need that. See: python/typing#572 for a description, including the below workaround. Protocol doesn't give us any special run-time behavior (except for runtime_checkable,) and can be pretty transparently swapped out for Generic at run time. By using Generic at run-time, we get the expected __init__ behavior. But, we still want Protocols at type-checking time because Protocol is much stricter about assigning to `self` without explicitly defining and typing the object variable. In conclusion, I'm sorry. Hopefully python/typing#572 gets fixed and we can delete this and go back to the isinstance check in deployment.py. Co-authored-by: Graham Christensen <[email protected]>
Explicitly subclassed Protocols don't support super().__init__ ... but we need that. See: python/typing#572 for a description, including the below workaround. Protocol doesn't give us any special run-time behavior (except for runtime_checkable,) and can be pretty transparently swapped out for Generic at run time. By using Generic at run-time, we get the expected __init__ behavior. But, we still want Protocols at type-checking time because Protocol is much stricter about assigning to `self` without explicitly defining and typing the object variable. In conclusion, I'm sorry. Hopefully python/typing#572 gets fixed and we can delete this and go back to the isinstance check in deployment.py. Co-authored-by: Graham Christensen <[email protected]>
Hi, I've just come across this in our testing when updating from 3.10.0.b4 to 3.10.0.rc1. In my case, the protocol classes don't have an I can't see what the change is in the 3.10 release notes, maybe the fix for runtime_checkable protocols with only attributes? (But we have methods, just no init().) |
@Yobmod this bug has been open for 3 years, I wonder if you did some research that ties such a very recent change to this bug in particular? |
@hauntsaninja Thanks for the heads-up! (I put in a workaround for now, but I'll check if fixed next rc). |
Closing here as this has been filed to bpo. |
A possible solution is to append a call to existing
__init__
while overwriting (after the check for_is_protocol=True
, where we unconditionally raise because protocols can't be instantiated). This way explicit non-protocol subclasses can use a protocol__init__
as a "default constructor". Default implementations are already supported for other protocol members, so it is natural to expect that__init__
is not different. See also python/mypy#3823cc: @JukkaL
The text was updated successfully, but these errors were encountered: