-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Self type with multiple inheritance #18458
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
This is trivial to fix (as far as I understand, that's just a bug, and diff --git a/mypy/checker.py b/mypy/checker.py
index 79d178f3c..06e31cddd 100644
--- a/mypy/checker.py
+++ b/mypy/checker.py
@@ -2232,8 +2232,8 @@ class TypeChecker(NodeVisitor[None], CheckerPluginInterface):
is_class_method = sym.node.is_class
mapped_typ = cast(FunctionLike, map_type_from_supertype(typ, sub_info, super_info))
- active_self_type = self.scope.active_self_type()
- if isinstance(mapped_typ, Overloaded) and active_self_type:
+ active_self_type = fill_typevars(sub_info)
+ if isinstance(mapped_typ, Overloaded):
# If we have an overload, filter to overloads that match the self type.
# This avoids false positives for concrete subclasses of generic classes,
# see testSelfTypeOverrideCompatibility for an example. However, To be clear, minimal unsafety illustration (crashes at runtime, accepted both by mypy and pyright): from typing import Self
class A:
def fn(self, other: Self) -> int:
return 0
class B(A):
foo: int = 0
def fn(self, other: Self) -> int:
return other.foo
def handle(obj: A) -> None:
obj.fn(A())
handle(B()) We need a better approach to Self type in method arguments (actually IMO we need to prohibit it entirely, but I probably won't be heard). |
From the very beginning we new that self types are inherently unsafe. It was kind of a conscious trade-off, as otherwise they will be a pain to use. |
This very problem is not about |
When I say from the very beginning I mean from the very beginning. What you call "with explicit typevars" is also called self-types, since it works not just because this is how type variables work, there are specific code paths that were added to support this pattern, note the title of #2193 (and this is btw how |
Not sure whether this is actually a bug or not, but I'm getting a base class incompatibility error when inheriting from two classes defining a method with the same signature containing the
typing.Self
type.To Reproduce
Running
mypy
gives this error:I expected
Self
to mean "whatever this type happens to be" (base class or subclass) but the error would suggest that it's interpretingSelf
as the specific class containing that method definition.Next I tried the following variation:
This fixes the incompatibility error but results in new errors:
I also tried using two separate
TypeVar
s, one withbound='A'
and the other withbound='B'
, but this brought back the "incompatible definition" error from before.Finally (after reverting the types back to
Self
), I updatedC
's definition to the following:This ended up type-checking, but I'm wondering if
mypy
ought to be clever enough to figure it out without having to explicitly overridemethod
, or if there's some other alternative?And if not, perhaps the error message about the incompatible definition could elaborate a bit more in the case where the type signatures "appear" to match due to the use of
Self
?Environment
mypy
1.14.1 (no flags or config file)The text was updated successfully, but these errors were encountered: