My own experience is I have passed abstract classes to type[T] where function was able to handle that without an issue. Passing a type does not imply the use case is to instantiate it directly. I don’t think I have examples of passing protocol to a type[T], although that’s because I tend to see more libraries with abstract classes then protocols. There’s a lot of common abstract classses in standard library but few (not sure of any) protocols there. I do not see a strong argument for why protocols vs abstract classes should differ in rules here.
So my own preference would lean towards,
variables and parameters annotated with type[Proto] accept only concrete (non-protocol) subtypes of Proto
removing this entirely.
If not then how should code that does runtime type manipulations (singledispatch/config systems) handle this? We could have type[T] and ConcreteType[T] (or AbstractType[T]), but unsure extra special form is worth distinguishing the two. If answer is no option, then it mostly becomes noisy type ignore.
edit: context:global ": type[T… - Sourcegraph we can review usage patterns of type[T]. Too many to review but spot checking 4,
First one uses it for a cast and abstract/protocol would work fine. Second one modifies class attributes for documentation. That would work fine too with protocol. Third one is interesting. It does not work with protocols, but it also does not work with most concrete types. It is only for TypedDict types so really it’s closer to type[T: TypedDict] even though that’s not well defined in type system either. Fourth one looks like Self maybe written before Self existed?