You make a valid point about the naming suggesting behaviour that doesn’t line up with what I’m describing. On second thoughts, using ConcreteType and Type actually makes much more sense as the naming is more clear.
I initially didn’t suggest this as I was concerned that the changes would cause a decrease in code safety, since unsafe behaviour (instantiating an abstract class) would then be possible in code, since the existing error would no-longer apply. However, I didn’t realise that this would be addressed by the new error this could introduce (attempt to instantiate an abstract class), meaning that the locations where this reduced safety affects the code would be more apparent.
My only concern with this would be that this would be bad for backwards compatibility for Mypy, as unmaintained libraries would lose some degree of type safety for users (who in future would assume that anything annotated with Type won’t be instantiated, as proposed by this change) of libraries that didn’t change all their definitions.
So essentially, using ConcreteType for types that can be instantiated would be much more clear, but may cause problems for backwards compatibility in Mypy (although given that this is an inconsistency compared with other type checkers, this might not be a huge issue). Using AbstractType for types that cannot be assumed to be safe to instantiate is less clear, but will cause fewer issues for users of Mypy, potentially at the expense of users of other type checkers.
I’d love to hear more opinions on which of these makes the most sense to everyone. In particular I’d like to hear from some people that use Pyright a bit more, since I’m less familiar with it. How would each option affect your code?