I am having this issue as well. I am not sure why an object of type Any should automatically be accepted as a base class. For example, calling f(3) satisfies f's type definition, but 3 would not make for a valid base class. So, I would say that both f and g should error (maybe not for the reason that f errors today).
@Victor-Savu Any should be accepted as a base class because that's the point of Any; it's an object on which any operation is valid. It's essentially a way to tell the type checker to trust the programmer. Of course f(3) will fail at runtime and the type checker won't catch it, but that's the cost of using Any.
Your example also seems like a bug to me, but it's not quite the same as this one. Feel free to report a new issue.
The mypy error in the comment above is useful and should be raised even after this issue is fixed. It should probably get a better message. Something like: error: "an_object" cannot be used as a base class because its type is "object", which is not a subclass of "type"
On the other hand, if we fix the problem, the runtime error will be detected ahead of time by mypy as well.
defsubclass(a_type: type) ->type:
classA(a_type): pass# error: Invalid type "a_type", Invalid base classreturnAdeftest_subclass() ->None:
assertisinstance(Exception, type)
assertisinstance(subclass(Exception), type)
assertissubclass(subclass(Exception), Exception)
assertisinstance(1, object)
withpytest.raises(TypeError):
subclass(1) # error: Argument 1 to "subclass" has incompatible type "int"; expected "type"
The code above should only have one type error (the last line) as the error on the second line is caused by the current issue.
I'll add here another case, which I believe is related, even though I'm not sure to understand all the whys and wherefores.
fromtypingimportTypeclassA: passa=Aa2: Type[A] =A# OkclassB(a): pass# OkclassB2(a2): pass# Errors: not valid as a type; Invalid base classdeff(cv: Type[A]):
classB3(cv): pass# Errors: not valid as a type; Invalid base classreturnB3f(a) # Okf(a2) # Ok
I would expect that if I promise the type checker that my variable is of the class type, it would accept it as base class. Is there some subtleties I don't get?
@frankie567 a = A creates a type alias. mypy doesn't allow these to rebound and they are special in some other ways. a2: Type[A] = A creates a variable, and it could be assigned a new value elsewhere. In particular, it could be bound to a subclass of A that mypy doesn't know anything about.
That's why mypy complains about using a2 as a base class -- for example, mypy can't bind super().__init__ correctly since a2 could refer to a subclass of A that changes the signature of __init__. Also, method overrides can't be checked, since there may be additional methods mypy doesn't see.
importtyping# worksbase=objectclassC(base):
passdeff1() ->None:
base=objectclassC(base): # Variable "base" is not valid as a type / Invalid base class "base"passdeff2(base: typing.Any) ->None:
classC(base): # Variable "base" is not valid as a type / Invalid base class "base"pass# worksdeff3(base: typing.Any) ->None:
base2: typing.Any=baseclassC(base2):
pass
Any update on this issue? It's quite a big one IMO.
Reacted by Andy , Luca Soldaini, Pedro Fonini, Sam Pegler, Lukas Juhrich, Daniel Fainberg, monkeyusage, Alex Ray, cristiciortea, Eugene Korostylov and 8 more
One more case, very similar to @blueyed's, but in the context of a classmethod -- and I also found a third incorrect error message (name-defined) that I don't think was mentioned yet in this thread: even though cls has type type[C] where C is bounded by MyClass, mypy is unable to resolve the reference to cls.InnerClass.
fromtypingimportTypeVarC=TypeVar("C", bound="MyClass")
classMyClass:
classInnerClass:
pass@classmethoddefdynamic_subclass(cls: type[C]) ->type[C]:
# Mypy emits two errors on the following line:# error: Variable "cls" is not valid as a type [valid-type]# error: Invalid base class "cls" [misc]classMySubClass(cls):
# Mypy emits one error on the following line:# Name "cls.InnerClass" is not defined [name-defined]classMySubInnerClass(cls.InnerClass):
passpassreturnMySubClass# to show that everything works as expected at runtime:SubClass=MyClass.dynamic_subclass()
my_subclass_instance=SubClass()
Activity
Victor-Savu commented on May 5, 2019
I am having this issue as well. I am not sure why an object of type Any should automatically be accepted as a base class. For example, calling f(3) satisfies f's type definition, but 3 would not make for a valid base class. So, I would say that both f and g should error (maybe not for the reason that f errors today).
In my example, I use Type[T]:
I would expect h to be accepted here because tp is declared as a type.
JelleZijlstra commented on May 5, 2019
@Victor-Savu Any should be accepted as a base class because that's the point of Any; it's an object on which any operation is valid. It's essentially a way to tell the type checker to trust the programmer. Of course f(3) will fail at runtime and the type checker won't catch it, but that's the cost of using Any.
Your example also seems like a bug to me, but it's not quite the same as this one. Feel free to report a new issue.
Victor-Savu commented on May 5, 2019
Hi @JelleZijlstra! Thank you for the explanation! I went back to the documentation and I am convinced you and @JukkaL are right that the code in the first comment should produce not errors in mypy. I found this stack overflow response very helpful as well.
I would still like to make the point that not any object that is taken in as an argument should be accepted by mypy:
The mypy error in the comment above is useful and should be raised even after this issue is fixed. It should probably get a better message. Something like: error: "an_object" cannot be used as a base class because its type is "object", which is not a subclass of "type"
On the other hand, if we fix the problem, the runtime error will be detected ahead of time by mypy as well.
The code above should only have one type error (the last line) as the error on the second line is caused by the current issue.
frankie567 commented on Oct 30, 2019
I'll add here another case, which I believe is related, even though I'm not sure to understand all the whys and wherefores.
I would expect that if I promise the type checker that my variable is of the class type, it would accept it as base class. Is there some subtleties I don't get?
JukkaL commented on Oct 30, 2019
@frankie567 a = A creates a type alias. mypy doesn't allow these to rebound and they are special in some other ways. a2: Type[A] = A creates a variable, and it could be assigned a new value elsewhere. In particular, it could be bound to a subclass of A that mypy doesn't know anything about.
That's why mypy complains about using a2 as a base class -- for example, mypy can't bind super().__init__ correctly since a2 could refer to a subclass of A that changes the signature of __init__. Also, method overrides can't be checked, since there may be additional methods mypy doesn't see.
frankie567 commented on Oct 30, 2019
@JukkaL Thank you for this explanation, I understand now 🙂Sorry for the noise on the ticket!
blueyed commented on Nov 7, 2019
This does not only affect bases from args, but also the local scope / function body.
I've looked a bit into why the following is not working, and it appears to be due to the fact that configure_base_classes does not know about base:
mypy/mypy/semanal.py
Lines 1472 to 1477 in a94e649
There is some code in analyze_function_body already to bind things into the local scope, but it appears to not work here correctly / as expected?:
mypy/mypy/semanal.py
Lines 897 to 917 in a94e649
mypy 0.750+dev.a94e649de794ecd169a5bcc42274e5205ffbb1fb
youtux commented on May 21, 2022
Any update on this issue? It's quite a big one IMO.
maxbane commented on Nov 14, 2022
One more case, very similar to @blueyed's, but in the context of a classmethod -- and I also found a third incorrect error message (name-defined) that I don't think was mentioned yet in this thread: even though cls has type type[C] where C is bounded by MyClass, mypy is unable to resolve the reference to cls.InnerClass.
Allow function arguments as base classes (#14135)