Signature enforcement doesn't allow edge cases with **kwargs about overrides HOT 10 CLOSED

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 --strict. I think that overrides has the opportunity to be strict by default, because it has much fewer users than mypy. What do you guys think?

from overrides.

Thanks @cboots extremely interesting edge case and good point about getting the error message improved!

from overrides.

So named and positional arguments should be checked separately.

from overrides.

@cboots I think the problem is that x can be passed as a positional or keyword argument in A, but only as a keyword argument in B. In other words, a.methoda(1) is a valid call on A but b.methoda(1) does something completely different on B. Changing the signature of A.methodA to def methoda(self, *, x=0) resolves this ambiguity. The error message can definitely be improved though.

class A(EnforceOverrides):
    def methoda(self, *, x=0):
        pass

class B(A):
    @overrides
    def methoda(self, y=1, **kwargs):
        pass

from overrides.

Mentioned in another issue, but there's also some relevant discussion on enforcement considerations in python/mypy#6709.

from overrides.

I think named and positional arguments should be checked separately.

from overrides.

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

from overrides.

Added as a test to master ac8012f

from overrides.

Fixed after dc3b449

from overrides.

@cboots we now have 5.0.0b0 out. This should fix the issues that you have reported.
Could you test this pre-release version to ensure that everything works?

from overrides.