Repository navigation
Type inference problem in generic function #603
Description
Mypy complains about the following code:
from typing import TypeVar, List
T = TypeVar('T')
def f(a: T) -> None:
l = [] # type: List[T] # Error, even though this should be fine
The reason for the error seems to be that the type variable type T in List[T] is erased so that it won't conflict with the type variables used for inferring the type of the list expression. Both type variables should be able to coexist during type inference.
Activity
rwbarton commentedon Apr 8, 2016
I took a quick look at this bug first because it seems pretty fundamental to some of the inference problems involving type variables. Indeed as Jukka says the problem is that function type variables get "erased" from the type of the context when checking a call to a generic callable, making them not valid solutions for the type arguments of that call.
The reason is that in a nested call like
we first try to figure out what type
mksetis being called at, by determining the type of its arguments; calling that type to be determinedT1, we next need to determine what typemklistis being called at. Based on the fact that the return type ofmklistneeds to beList[T1], we would conclude thatmklistis called at typeT1. But its argument has typebool, and we don't know that that is the same asT1, causing an error.By erasing the type variable
T1from the context when type checkingmklist(b), we prevent solving for the type variable ofmklistbased on the return type, so instead it gets solved based on the argument typebool. Then when finishing the type checking ofmkset(...), we know the argument has typeList[Bool]soT1must beBool. This approach seems like a bit of a hack, but I guess it works well for now. (The alternative is for type checking ofmklist(b): List[T1]to be able to return a result like "yes, providedT1 = Bool" and then take this into account when inferring the type variables ofmkset.)Turning to the program in this ticket, the problem is that we also erase the type
Tfrom the context of[], because we currently have no way to distinguish type variables bound by a surrounding function definition from type variables that we are solving for in a surrounding function call. In general we might even be typechecking inside a function call that is a call to a surrounding function definition, for example in a generic functionfthat calls itself recursively. So at a minimum, we need to do some kind of relabeling of the type variables of the call tofto distinguish them from the type variables bound by the definition off. This would still be true even if we implemented #1261, or replaced the context type variable erasure with an approach based on returning constraints from type checking.This ought to be enough for now since when relabeling type variables of a generic call, we can mark them as "erasable", and erase only those type variables in context type variable erasure. But since this isn't trivial to do, I'm going to investigate some related bugs before deciding whether to go down that path.
Replace class/function distinction with plain/metavariable distinction
Replace class/function distinction with plain/metavariable distinction
Improve type checking of generic function bodies (#1580)