GeezerVison

Please don't. This will break future innovation in the type system (e.g., making new typing primitives in typing-extensions). We don't need to be strict about allowed types in the typing.py runtime; that's what static type checkers are for.

Please don't. This will break future innovation in the type system (e.g., making new typing primitives in typing-extensions). We don't need to be strict about allowed types in the typing.py runtime; that's what static type checkers are for.

In addition, this breaks cpython internal typeforms that need to be able to pass through _type_check without importing typing: I need dataclasses.InitVar to do it in #30997.

Do typing primitives in typing-extensions subclass any typing class? If yes, it can be included in the list of allowed types. If no, we perhaps could use duck-typing: check for some attributes, like __parameters__.

Alternatively we can remove all checks.

dataclasses.InitVar doesn't subclass anything, and it's not acceptable to make dataclasses import typing. So this won't work.

Duck typing moves the reason __call__ is a bug magnet to another attribute that people won't notice until it's in the final code: an odd requirement not noticed because of the rarity of _type_check in actual type annotations. I support removing all the checks like I did in #31151. The only remaining check there is for tuple, but not for type reasons: it's because it's used to disallow multiple arguments by typeforms.