bpo-46644: No longer accept arbitrary callables as type arguments in generics - #31159
bpo-46644: No longer accept arbitrary callables as type arguments in generics#31159serhiy-storchaka wants to merge 2 commits into
Conversation
Sorry, something went wrong.
sobolevn
left a comment
There was a problem hiding this comment.
I am +1 on this version of this PR 👍
Sorry, something went wrong.
| return f | ||
|
|
||
|
|
||
| class NewType: |
There was a problem hiding this comment.
What was the reason to move this definition?
Sorry, something went wrong.
There was a problem hiding this comment.
_type_check() was used before defining NewType.
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
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. |
Sorry, something went wrong.
| No longer accept arbitrary callables as type arguments in generics. E.g. | ||
| ``List[chr]`` is now an error. |
There was a problem hiding this comment.
This patch does not make List[chr] an error. _type_check is not called in this code path.
Sorry, something went wrong.
There was a problem hiding this comment.
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>.
Sorry, something went wrong.
There was a problem hiding this comment.
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
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
https://bugs.python.org/issue46644