-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Provide decorator for unsafe overrides #5704
Comments
I think this is a more general problem. I have seen this some many times in different contexts. It is not possible to rename this, but maybe we can add a large note somewhere early in the docs explaining that |
I like the idea of a decorator to flag unsafe overrides.
|
One additional weakness of the When the type signatures are different, the overload resolution uses both sets of signatures for the function. An example might go something like this: class Foo:
def __eq__(self, x: int) -> Expression:
assert isinstance(x, int)
# ...
reveal_type(Foo() == 1) # Expression
reveal_type(Foo() == '1') # bool (!!!) The expected result would be something like Argument 1 to "__eq__" of "Foo" has incompatible type "str"; expected "int" I imagine this is the way it is because we've disabled the type check, so there are implicit assumptions in the code that are no longer true. When we go to implement the |
|
I'm less concerned about the ignore on the override itself (I agree the new code-specific stuff will make that safer as far as specificity), but the downstream type signature that seems to be a union of the two signatures, something that I haven't seen elsewhere. Just to reiterate my example with a bit more detail + up-to-date mypy output:
Lines 15 and 16 should either both reveal
It seems like there must be some special magical handling for |
I think |
Unsafe overrides are pretty common when annotating legacy codebases. The recommended way to deal with this is to add a
# type: ignore
comment. This has a few major issues, though:# type: ignore
and believe that it ignores the type annotation, even though it only ignores the error message.# type: ignore
can ignore unrelated errors that the user doesn't want to be ignored.I propose to add a decorator that can be used to silence this error, and only this error. Example:
This would have these benefits:
See #2783 and #1237 for relevant previous discussions.
The text was updated successfully, but these errors were encountered: