-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Incompatible singledispatch signature not detected #11734
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
Comments
Example 1 should be relatively easy to support, but examples 2 and 3 have some subtlety involved. For example 2, I don't know if we should allow arguments of registered implementations to be subtypes of the corresponding main singledispatch function's arguments, or whether we should require that they be the exact same types. Example: from functools import singledispatch
class A: pass
class B(A): pass
@singledispatch
def f(x: object, y: A) -> None:
y + ''
@f.register
def g(x: int, y: B) -> None:
y + 1 Allowing subtypes for the arguments could allow directly calling On the other hand, allowing subtypes could mask errors when calling Example 3 seems like a I still think it's worth trying to show an error for, but we might have to abandon it if there are too many false positives. Alternatively, we could try putting this error behind a flag that gets enabled by |
I think that they should be allowed to vary contravariantly (i.e. registered implementations can use a more general type, but not a narrower subtype). This would be consistent with how method overriding is type checked.
Yeah, it would be reasonable to not require argument names to be consistent, since we don't check them in other contexts. |
This generates no error from mypy but fails at runtime:
Another example:
Third example:
We should check that the signatures of registered items are compatible with the generic one, except for the first argument.
The text was updated successfully, but these errors were encountered: