Warn about unconstrained typevars

[JelleZijlstra]

I think code like this should produce an error:

def f(x: AnyStr) -> None: ...

because there's nothing to constrain the type variable. There is a good amount of code like this in typeshed.

I'm not sure how easy this would be to implement. Maybe it should be behind a flag at first; I imagine this proposed change may lead to a lot of new errors, but it's a good way to educate people about what typevars are for.

[JukkaL]

The example is actually okay -- the type of an argument at a call site will be used to infer a value for the type variable. It's not recommended since Union[str, bytes] or similar is more general, as it also accepts unions, and it allows mypy to generate better error messages. Arguably mypy could be improved to make the AnyStr version as good as the union version, but there are a few open issues that would need to be fixed first (#963 and #1943).

[JelleZijlstra]

I guess that depends on what you consider OK; the example doesn't compromise type safety or create false positive errors, but it's using a harder-to-understand part of the type system (type variables) when a simpler solution (unions) is available and should have the same results.

That line of argument applies even more strongly if you use a typevar without bounds, like this:

T = TypeVar('T')

def f(x: T) -> None: ...

[JelleZijlstra]

This is essentially the same as #2885 except that it talks about argument rather than return types, so closing.