I've also posted this on the discuss.python.org forum, but as suggested in PEP 1, I'm also posting here to get additional ideas/feedback/criticism. Currently, using a `type[Something]` annotation requires the given type to be a concrete class in Mypy and Pyright, which is often useful, since it means that the class can be safely instantiated within the code using the annotated object. However there are cases where a class does not need to be instantiated in order to operate on it. Here is a (somewhat contrived) example: ``` from abc import abstractmethod class Abstract: @abstractmethod def foo(self): pass class Concrete(Abstract): def foo(self): print("bar") def my_special_isinstance(o: object, t: type[Abstract]) -> bool: return isinstance(o, t) my_special_isinstance(Concrete(), Abstract) # Only concrete class can be given where "Type[Abstract]" is expected [type-abstract] ``` Note that in reality, my code that reproduces this would be far more complex (rather than just being a wrapper around isinstance). Some other examples can be found in this issue . It’s clear that unless type safety is reduced for other cases, this case will never satisfy mypy, and as such I believe the best solution is to implement a separate type annotation for this case, tentatively named `AbstractType` (although `Interface` was also suggested). This could come with a few benefits: * Functions using it as an annotation could be prevented from attempting to instantiate the abstract class * The type annotation could give users of libraries that utilise it a bit more information on how the function behaves (ie knowing the class isn’t instantiated, or knowing not to instantiate a class returned by it) * It would be possible to make the above example type-safe with relatively trivial edits (changing `type[Abstract]` to `AbstractType[Abstract]`) As far as I can tell, this is the best compromise to allow for code such as the above to be type-safe without reducing type safety for other code (thereby ensuring backward compatibility). What does everyone think? I'd love to hear other ideas, or criticism and feedback on this one. If the idea seems reasonable, I'm also happy to start drafting a PEP for it!