Mypy complains when passing a type variable to a generic class as a constructor argument

[Mr-Pepe]

Bug Report

Mypy reports type errors but Pylance successfully provides autocompletion for the following code sample.

To Reproduce

from typing import Generic, Optional, Type, TypeVar


class Car:
    ...


class FastCar(Car):
    def go_fast(self) -> None:
        ...


class SlowCar(Car):
    def go_slow(self) -> None:
        ...


T = TypeVar("T", bound=Car)


class Driver(Generic[T]):
    def __init__(self, car_type: Type[T] = FastCar):
        self.car = car_type()


driver1 = Driver()
driver1.car.go_fast()

driver2 = Driver(car_type=SlowCar)
driver2.car.go_slow()

I have a library with a base class Car and several sub-classes for different kinds of cars. A Driver gets assigned their type of car during instance creation. A certain car type is used as the default. VS code correctly provides autocompletion for the car attribute of each driver, without requiring the user to specify the car type twice, like driver1 = Driver[SlowCar](car_type=SlowCar). However, Mypy is not happy.

Actual Behavior

tmp.py:22: error: Incompatible default for argument "car_type" (default has type "Type[FastCar]", argument has type "Type[T]")  [assignment]
tmp.py:27: error: Need type annotation for "driver1"  [var-annotated]
Found 2 errors in 1 file (checked 1 source file)

I can not make sense of the first error because T is bound to Car and FastCar is a sub-class of Car. What should I use here instead?

Mypy should consider the default argument to the __init__ method and not show the second error. Either adding the car type explicitly (driver1 = Driver(car_type=FastCar)) or adding the car type in brackets (driver1 = Driver[FastCar]()) solves the second error but I don't want to put that burden on the user.

I could add a # type: ignore to the __init__ method and remove the default car type. That would give users autocompletion in VS code and silence Mypy but that doesn't feel clean. Am I misusing the generic annotation by passing it as an argument instead of providing it in brackets?

Your Environment

• Mypy version used: 1.2.0
• Python version used: 3.9

[A5rocks]

I can see the argument for using default args to try to infer type variables. As such, I do believe that is a valid issue.

However:

1. Type var defaults are a PEP that will likely be accepted soon, meaning you can provide a default for T.
2. type[T] = FastCar is not valid, as mypy points out:

from typing import Generic, TypeVar

T = TypeVar("T", bound=object)

class H(Generic[T]):
  def __init__(self, x: type[T] = int):
    ...

H[str]()  # this should not be allowed.

Just substitute FastCar for int, Car for object, and another subclass of Car as str.

[Mr-Pepe]

Type var defaults are a PEP that will likely be accepted soon, meaning you can provide a default for T.

Nice!

type[T] = FastCar is not valid, as mypy points out:

Sorry, I still don't understand what the problem is. Why do I get correct autocompletion in VS Code for your example although the type hinting is not valid? Changing it to the following makes Mypy happy but also removes the default:

from typing import Generic, TypeVar

T = TypeVar("T", bound=object)

class H(Generic[T]):
    def __init__(self, x: type[T]):
        ...

a = H(x=str)

What would that example look like with PEP696 accepted? Like this?

from typing import Generic, Sequence, TypeVar

T = TypeVar("T", bound=Sequence, default=list)

class H(Generic[T]):
    def __init__(self, x: Sequence = list):
        ...

But then I'd still have to define the type twice, once for type checking and once for runtime behavior, e.g., H[tuple](x=tuple), right?

I guess I'll have to remove the default value for now.

[A5rocks]

Uhh, in a nutshell my example is pointing out: Driver[SlowCar]().car.go_slow().

And yeah even with PEP 696 you will need to specify the type twice -- or you can specify it once at runtime and have mypy infer the typevar!

[A5rocks]

Since another person's fallen for this trap (which I get, I think it's pretty easy to get mistaken over how typevars can be bound to subtypes), here's how their (the other person's but a similar method works for code above) code could show type unsafety:

from typing import TypeVar

class A:
    pass


T_A = TypeVar("T_A", bound=A)


def f(a: T_A = A()) -> T_A:  # this is currently not allowed
    return a

class B(A):
  z: int

x: B = f()  # this is currently accepted, as it should be
x.z  # if mypy allowed `A` to be assigned as a default without error, then this would be buggy

... with that said, I kinda take back my initial statement about inferring T_A. I don't think I really thought everything through. I don't really think this issue makes sense if we're talking about type safety. Maybe some better error signalling?

[Gobot1234]

Since another person's fallen for this trap (which I get, I think it's pretty easy to get mistaken over how typevars can be bound to subtypes), here's how their (the other person's but a similar method works for code above) code could show type unsafety:

from typing import TypeVar

class A:
    pass


T_A = TypeVar("T_A", bound=A)


def f(a: T_A = A()) -> T_A:  # this is currently not allowed
    return a

class B(A):
  z: int

x: B = f()  # this is currently accepted, as it should be
x.z  # if mypy allowed `A` to be assigned as a default without error, then this would be buggy

... with that said, I kinda take back my initial statement about inferring T_A. I don't think I really thought everything through. I don't really think this issue makes sense if we're talking about type safety. Maybe some better error signalling?

FWIW pyright reports an error on "this is currently accepted, as it should be"

which is what you're taking back right?

[A5rocks]

I... huh.

That's weird. I didn't realize pyright would flag user code for library code (at least in my mind) problems like that. I guess mypy could do that in the interest of practicality but that's just weird.

[erictraut]

I didn't realize pyright would flag user code for library code ... problems like that.

I'm not sure what you mean by "flagging user code for library code". Pyright flags this as an error because f() evaluates to A, which isn't type compatible with x's declared type of B. The error is in the usage of f, not in the declaration of f.

FWIW, pyright type checks the sample at the top of this thread without errors, and it properly reports an error with Driver[SlowCar]().car.go_slow().

[A5rocks]

Huh, turns out this is has been reported a ton before; see #3737

[erictraut]

Yes, I think this is a duplicate of #3737.