Static type checkers already need to handle the case where the type of a base class cannot be determined statically and is therefore treated as `Any`. This can occur for many reasons including dynamic code, failure to resolve an import at static analysis time, etc. Disallowing an explicit `Any` from being used as a base class doesn't eliminate the problem.

I agree with your observation that this case isn't well spec'ed and creates potential inconsistencies in the type system. It also potentially leads to differences in behavior across type checkers, since the behavior isn't precisely spec'd. In practice, this hasn't been a problem. Type checkers do "the obvious thing" when they encounter an `Any` base class. This can lead to false negatives, but that's generally true for `Any`.

I think this is a case where it's more important to be pragmatic than to be technically correct. And I don't see any benefit to deprecating the use of `typing.Any` as a base class at runtime.

Eric Traut
Contributor to pyright & pylance
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: sergei.a.lebedev@gmail.com