Ivan Levkivskyi

And also yes, having this as a side effect of a _stub_ package, will make it even harder to detect.

Probably another example of issue caused by `expand_type()` calling `make_simplified_union()`. I was recently thinking about this but still don't have a good solution.

A simple repro test case is ``` [case testCallableUnionCB] from typing import Union, Callable, TypeVar TA = TypeVar("TA", bound=A) class A: def __call__(self: TA, other: Union[Callable, TA]) -> TA: ......

Sorry, this is volunteer run and people may just not have time to look at this. As for reviewers, I guess @hauntsaninja may be a good person to look at...

The point is that it is too hard to track which classes are instantiated in the body of a given function, and which are not. If we would have such...

> I'm not sure what's the best way to move forward, though. A possible ad-hoc solution (which may be not so bad), is to just remove this check for class...

I think assigning this a dedicated error code is a good idea. Finding a good compromise for everyone may be hard, and with e.g. `--disable-error-code=typevar-abstract` people will be able decide...

Yeah, I was thinking about this, but this will require a PEP probably, and all other type-checkers will need to agree on exact semantics. This may take a lot of...

> Would also an implementation over TypeGuard be possible? So that you can tell TypeGuard somehow that only concrete classes can be returned No, this will not help.

The dedicated error code for this landed and will be available in the next release. You can opt-out from this check using `--disable-error-code=type-abstract` (or using your config file).