Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented Feb 6, 2022

Copy link
Member

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am +1 on this version of this PR 👍

@@ -2065,6 +2064,50 @@ class Other(Leaf): # Error reported by type checker
return f


class NewType:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was the reason to move this definition?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_type_check() was used before defining NewType.

@JelleZijlstra
Copy link
Member

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
Copy link
Contributor

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.

Comment on lines +1 to +2
No longer accept arbitrary callables as type arguments in generics. E.g.
``List[chr]`` is now an error.
Copy link
Contributor

@GBeauregard GBeauregard Feb 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>.

Copy link
Contributor

@GBeauregard GBeauregard Feb 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

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
Copy link
Contributor

GBeauregard commented Feb 6, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants