-
Notifications
You must be signed in to change notification settings - Fork 32
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
Signature enforcement doesn't allow edge cases with **kwargs #61
Comments
Thanks @cboots extremely interesting edge case and good point about getting the error message improved! |
So named and positional arguments should be checked separately. |
@cboots I think the problem is that class A(EnforceOverrides):
def methoda(self, *, x=0):
pass
class B(A):
@overrides
def methoda(self, y=1, **kwargs):
pass |
Mentioned in another issue, but there's also some relevant discussion on enforcement considerations in python/mypy#6709. |
To summarize the discussion, the mypy contributors agree that this is an invalid override but are worried about breaking too many people if they start checking it now. It will; however, check this if |
I think named and positional arguments should be checked separately. |
From original example # positional checking
A().methoda()
B().methoda()
# -> ok
A().methoda(1)
B().methoda(1)
# -> ok -> positionals match
# named checking
A().methoda(x=3)
B().methoda(x=3)
# -> ok -> named match
# -> B.methoda signature overrides A.methoda signature |
Added as a test to master ac8012f |
Fixed after dc3b449 |
@cboots we now have 5.0.0b0 out. This should fix the issues that you have reported. |
I'm happy to see signature enforcement feature, cool stuff, but it broke how I was doing inheritance in my library. Maybe I'm wrong to do this, but it's valid python and it seems to be a missed edge case.
Here's a toy example that exposes the issue. In this design pattern the base class has a concrete set of optional parameters that I want to be able to add to in the future without updating every subclass to add the same optional arguments and defaults. The base class is the source of truth for this behavior.
Subclasses can add their own unique parameters to the signature, and pass the remainder on to the superclass without requiring knowledge of the signature or duplication of the default parameters.
However, this results in this stack trace:
As a side note, it took me a bit to track down the issue because the TypeError didn't specify which method was missing the parameter "x". That would be a nice enhancement to the message to include the function name.
I found I could get around the issue by changing the base class to use **kwargs, but I'd prefer not to have to do that for readability.
The text was updated successfully, but these errors were encountered: