8000 gh-118168: Fix Unpack interaction with builtin aliases by JelleZijlstra · Pull Request #118169 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

gh-118168: Fix Unpack interaction with builtin aliases #118169

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

Merged
merged 2 commits into from
Apr 23, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions Lib/test/test_typing.py
Original file line number Diff line number Diff line change
Expand Up @@ -978,6 +978,38 @@ def foo(**kwargs: Unpack[Movie]): ...
self.assertEqual(repr(foo.__annotations__['kwargs']),
f"typing.Unpack[{__name__}.Movie]")

def test_builtin_tuple(self):
Ts = TypeVarTuple("Ts")

class Old(Generic[*Ts]): ...
class New[*Ts]: ...

PartOld = Old[int, *Ts]
self.assertEqual(PartOld[str].__args__, (int, str))
self.assertEqual(PartOld[*tuple[str]].__args__, (int, str))
self.assertEqual(PartOld[*Tuple[str]].__args__, (int, str))
self.assertEqual(PartOld[Unpack[tuple[str]]].__args__, (int, str))
self.assertEqual(PartOld[Unpack[Tuple[str]]].__args__, (int, str))

PartNew = New[int, *Ts]
self.assertEqual(PartNew[str].__args__, (int, str))
self.assertEqual(PartNew[*tuple[str]].__args__, (int, str))
self.assertEqual(PartNew[*Tuple[str]].__args__, (int, str))
self.assertEqual(PartNew[Unpack[tuple[str]]].__args__, (int, str))
self.assertEqual(PartNew[Unpack[Tuple[str]]].__args__, (int, str))

def test_unpack_wrong_type(self):
Ts = TypeVarTuple("Ts")
class Gen[*Ts]: ...
PartGen = Gen[int, *Ts]

bad_unpack_param = re.escape("Unpack[...] must be used with a tuple type")
with self.assertRaisesRegex(TypeError, bad_unpack_param):
PartGen[Unpack[list[int]]]
with self.assertRaisesRegex(TypeError, bad_unpack_param):
PartGen[Unpack[List[int]]]


class TypeVarTupleTests(BaseTestCase):

def assertEndsWith(self, string, tail):
Expand Down
5 changes: 3 additions & 2 deletions Lib/typing.py
Original file line number Diff line number Diff line change
Expand Up @@ -1786,8 +1786,9 @@ def __typing_unpacked_tuple_args__(self):
assert self.__origin__ is Unpack
assert len(self.__args__) == 1
arg, = self.__args__
if isinstance(arg, _GenericAlias):
assert arg.__origin__ is tuple
if isinstance(arg, (_GenericAlias, types.GenericAlias)):
if arg.__origin__ is not tuple:
raise TypeError("Unpack[...] must be used with a tuple type")
Comment on lines +1789 to +1791
Copy link
Member
@AlexWaygood AlexWaygood Apr 23, 2024

Choose a reason for hiding this comment

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

It feels weirdly inconsistent that we allow nonsensical things with the new syntax, but not with the "backwards-compatible syntax":

>>> from typing import TypeVarTuple, Unpack
>>> class Foo[*Ts]: ...
...
>>> Ts = TypeVarTuple("Ts")
>>> Bar = Foo[int, *Ts]
>>> Bar[*list[str]]
__main__.Foo[int, *list[str]]
>>> Bar[Unpack[list[str]]]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    Bar[Unpack[list[str]]]
    ~~~^^^^^^^^^^^^^^^^^^^
  File "/Users/alexw/dev/cpython/Lib/typing.py", line 394, in inner
    return func(*args, **kwds)
           ~~~~^^^^^^^^^^^^^^^
  File "/Users/alexw/dev/cpython/Lib/typing.py", line 1394, in __getitem__
    args = _unpack_args(args)
           ~~~~~~~~~~~~^^^^^^
  File "/Users/alexw/dev/cpython/Lib/typing.py", line 306, in _unpack_args
    subargs = getattr(arg, '__typing_unpacked_tuple_args__', None)
              ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/alexw/dev/cpython/Lib/typing.py", line 1791, in __typing_unpacked_tuple_args__
    raise TypeError("Unpack[...] must be used with a tuple type")
TypeError: Unpack[...] must be used with a tuple type

But I guess that's a preexisting problem, not new to this PR. We previously discussed the issue of "all generic aliases being unpackable" in #103450.

return arg.__args__
return None

Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
Fix incorrect argument substitution when :data:`typing.Unpack` is used with
the builtin :class:`tuple`. :data:`!typing.Unpack` now raises
:exc:`TypeError` when used with certain invalid types. Patch by Jelle
Zijlstra.
0