bpo-46644: No longer accept arbitrary callables as type arguments in generics

[serhiy-storchaka]

https://bugs.python.org/issue46644

[sobolevn]

I am +1 on this version of this PR 👍

[sobolevn]

What was the reason to move this definition?

[serhiy-storchaka]

_type_check() was used before defining NewType.

[JelleZijlstra]

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.

[GBeauregard]

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.

[GBeauregard]

This patch does not make List[chr] an error. _type_check is not called in this code path.

[serhiy-storchaka]

It does.

>>> List[chr]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/typing.py", line 317, in inner
    return func(*args, **kwds)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 1126, in __getitem__
    params = tuple(_type_check(p, msg) for p in params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 1126, in <genexpr>
    params = tuple(_type_check(p, msg) for p in params)
                   ^^^^^^^^^^^^^^^^^^^
  File "/home/serhiy/py/cpython/Lib/typing.py", line 184, in _type_check
    raise TypeError(f"{msg} Got {arg!r:.100}.")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Parameters to generic types must be types. Got <built-in function chr>.

[GBeauregard]

That code path is not used in type annotations; try a: List[chr] to reproduce the lack of error. I suppose it can show up in type aliases or get_type_hints, though.

EDIT: I retract this comment, see https://bugs.python.org/msg412662

[serhiy-storchaka]

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.

[GBeauregard]

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.