It's under-specified, and perhaps unfortunate, but the typing spec does actually permit inheriting from Any: https://typing.readthedocs.io/en/latest/spec/special-types.html#any

And this is used in typeshed (e.g. for unittest.mock.Mock): https://github.com/python/typeshed/blob/main/stdlib/unittest/mock.pyi#L109

This is already supported by the ClassBase enum: we should return Some(Self::Any) instead of None for KnownInstanceType::Any.

I've added some tests for subclasses; see below

I've added some tests for subclasses; see below

I think I've updated the inference logic correctly to treat instances of Subclass as if they were Any instead of Instance(Subclass). These lines both got assignment errors before the change.

I don't think we want to make that change; Subclass should still have the type Instance(Subclass), not the type Any. Our representation of the class Subclass will have Any in its method resolution order (MRO), which will impact how we treat it in some cases. For example, it should be assignable to any other non-final type, since it might be a subclass of that type, as mentioned below, and accessing an unknown attribute on it should give an attribute type of Any (the unknown base type might have that attribute, with some unknown type). But these are cases that we will implement in e.g. Type::is_assignable_to and Type::member, not by making the subclass of Any equivalent to Any.

I think this comment, and the line x: Subclass = 1, are not quite right; that latter assignment should be an error. Subclass is not equivalent to Any; it's a distinct class, which has an unknown base class. There is no "materialization" (using the term from the typing spec, to mean "replacing Any with a concrete static type") of the unknown base class that could possibly result in 1 being an instance of Subclass.

The second test line here is correct; since Subclass inherits from an unknown type, that unknown type could be (could materialize to) int or a subclass of int, therefore we should allow the assignment y: int = Subclass().

You can see that both pyright and mypy agree with this, via their online playgrounds.

Just for future reference, not because it's relevant to this PR: one place where I think mypy and pyright get it wrong is that they also allow the assignment x: Fin = Sub() in this code sample. Because Fin is a final class, it can have no subclasses, therefore the unknown base class of Sub can't materialize to Fin, therefore I don't think that assignment should be allowed. But this is for future: we don't even have support for final classes in red-knot at all yet.

I don't think we want to make that change; Subclass should still have the type Instance(Subclass), not the type Any. Our representation of the class Subclass will have Any in its method resolution order (MRO), which will impact how we treat it in some cases. For example, it should be assignable to any other non-final type, since it might be a subclass of that type, as mentioned below, and accessing an unknown attribute on it should give an attribute type of Any (the unknown base type might have that attribute, with some unknown type). But these are cases that we will implement in e.g. Type::is_assignable_to and Type::member, not by making the subclass of Any equivalent to Any.