Parameterless generic functions are allowed

[miedzinski]

from typing import TypeVar
T = TypeVar('T')
def f() -> T: ...

Mypy is absolutely OK with this code, but it makes no sense (it is not possible to return T without argument).

[ilevkivskyi]

I don't think mypy should necessarily prohibit something that "makes no sense". Could this cause a false positive or false negative (uncaught runtime error)? If yes, then those are bugs, if no, then there is no problem.

[miedzinski]

I disagree. You could say the same about usage of ClassVar in function signatures, but I'm pretty sure you think otherwise. :)

[ilevkivskyi]

These two cases are different. For ClassVar a user might expect some guarantees (like accepting only C.x as an argument of a function), that are in fact not provided, we want to avoid such situations. But what are the guarantees here that could be expected by a user but not actually provided? If you see them, then this might be a reason to "fix" this.

[miedzinski]

Okay, that's a point. On the other hand, I could see an user with poor understanding of generics writing something like

T = TypeVar('T')
U = TypeVar('U')
def f(x: T) -> U: ...

but as soon as he would provide some implementation for f (and it'd result in returning something other than None, assuming --strict-optional is off) mypy would throw an error.

If no one else considers this a bug, I can close this.

[JukkaL]

There actually is a valid reason to only use T in a return value type, at least if the return type is generic. A contrived example:

class MyList(List[T]): ...

def make_list() -> List[T]:
    return MyList()  # want to hide the implementation detail that it's actually a MyList

a: List[int] = make_list()

(Also, list() basically behaves like make_list in the above example, though it's a bit more complicated.)

However, I can't think of any real use case where plain T would be a reasonable return type if T is never used in an argument type. Warning about this would probably be a reasonable thing to do, but I agree with @ilevkivskyi -- it's not necessary for correctness. This issue can be left open, but this is a pretty low-priority thing unless it seems that users are confused by the current behavior.

[pkch]

IMO, identifying every possible non-sensical type annotation in mypy is unrealistic. So as with any apparently meaningless code, the question is how likely it is a symptom of a serious bug. If often, it could be reported as an error by mypy. If not too often, it might be something that could be caught by a linter such as pylint (if it becomes aware of mypy). This would be quite similar to how python interpreter accepts unused variables, but pylint complains about them.

[ilevkivskyi]

While thinking about whether there are possible use cases for returning a plain type variable I discovered that mypy behaves strangely in case of a restricted type variable:

from typing import TypeVar

class A: ...
class B: ...
T = TypeVar('T', A, B)

def f() -> T:
    if bool():
        return A() # E: Incompatible return value type (got "A", expected "B")
    else:
        return B() # E: Incompatible return value type (got "B", expected "A")

Note how two error messages contradict each other.

[sixolet]

Regarding @JukkaL's example of returning List[T], I think it would be kind to tell the user their line needs a type annotation rather than returning List[uninhabited] if the relevant line is a = make_list() instead of a: List[int] = make_list()