Nested TypeVar(bound=...) are not detected by reportInvalidTypeVarUse

[twoertwein]

Describe the bug
TypeVar(bound=...) are not detected by reportInvalidTypeVarUse when nested in Tuple/Type.

To Reproduce
I would expect that testE and testD create an error.

from typing import Tuple, Type, TypeVar

Bound = TypeVar("Bound", bound=int)
Unbound = TypeVar("Unbound")

def testA() -> Tuple[Unbound, ...]:  # error
    ...

def testB() -> Tuple[Type[Unbound], ...]:  # error
    ...

def testC() -> Unbound:  # error
    ...

def testD() -> Tuple[Bound, ...]:  # no error!
    ...

def testE() -> Tuple[Type[Bound], ...]:  # no error!
    ...

def testF() -> Bound:  # error
    ...

Additional context
https://github.com/pandas-dev/pandas/pull/43752/files#r716224377

[erictraut]

This is intended behavior. We exempt the following from the rule that a type variable can appear only once in a signature:

1. Constrained type variables
2. Bound type variables that are type arguments to other types (as in your example)
3. ParamSpecs

These all have legitimate uses when they appear once within a signature.

We previously didn't exempt 2, but we received bug reports requesting that we change it. The primary use case here is with invariant type variables. Consider the following:

class Animal: ...
class Bear(Animal): ...

TAnimal = TypeVar("TAnimal", bound=Animal)

def func1(a: List[Animal]):
    ...

def func2(b: List[TAnimal]):
    ...

bears = [Bear()]

func1(bears) # Generates an error
func2(bears)

While I think the above is a legitimate use case, I can't think of any legitimate use of a solitary bound type variable in a return type annotation, so perhaps the right answer here is to exempt this case only when the bound type variable is used in an input parameter annotation.

[erictraut]

I've implemented this change, and it will appear in the next release.

[twoertwein]

Thank you for the explanation and example! I honestly didn't know/forget that arguments to List and so on are treated invariant, which makes TypeVars a nice way to circumvent that.

Would it make sense to skip rules 2 if a bounded TypeVar is inside Type as Type is covariant (and Union[Type[TypeVar(bound=...)]])? It is not invalid, but it could be simplified.

[erictraut]

The rules for this check are already pretty complicated and difficult to explain to pyright users. Furthermore, there is a lack of consensus among the maintainers of typeshed and the type checkers about which cases are legitimate and which are not. We've had some good discussions about this on the typing-sig mailing list. If I remember correctly, pytype and pyright are more restrictive, whereas mypy doesn't flag any of these cases.

For these reasons, I'm reluctant to further complicate this check. The reason I think it's justifiable to handle return types as a special case here (i.e. the change that I just made) is that using a solitary bound TypeVar in this instance will likely result in other confusing behaviors after the call site, and there's value in warning the user that the problem is in the signature of the function. I can't think of any negative consequences of allowing a solitary bound TypeVar in an input parameter. So even if it's being used for a covariant or contravariant context, I don't think it's a problem.

[erictraut]

This is addressed in pyright 1.1.172, which I just published. It will also be in the next release of pylance.