Repository navigation
TypeVarTuple/ParamSpec bounds are checked too aggressively #151955
Description
Bug report
Bug description:
Currently:
>>> from typing import TypeVarTuple
>>> TypeVarTuple("Ts", bound=(int, str))
Traceback (most recent call last):
File "<python-input-1>", line 1, in <module>
TypeVarTuple("Ts", bound=(int, str))
~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/jelle/.local/share/uv/python/cpython-3.15.0b1-macos-aarch64-none/lib/python3.15/typing.py", line 206, in _type_check
raise TypeError(f"{msg} Got {arg!r:.100}.")
TypeError: Bound must be a type. Got (<class 'int'>, <class 'str'>).
>>> from typing import ParamSpec
>>> ParamSpec("P", bound=(int, str))
Traceback (most recent call last):
File "<python-input-3>", line 1, in <module>
ParamSpec("P", bound=(int, str))
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/jelle/.local/share/uv/python/cpython-3.15.0b1-macos-aarch64-none/lib/python3.15/typing.py", line 206, in _type_check
raise TypeError(f"{msg} Got {arg!r:.100}.")
TypeError: Bound must be a type. Got (<class 'int'>, <class 'str'>).Now, ParamSpec and TypeVarTuple bounds aren't formally specified as a part of the type system, but if they are to mean anything, a tuple actually is the right thing to use a bound for a TypeVarTuple. For a ParamSpec, a list would perhaps be the expected default, but I don't think we need to prohibit a tuple either. To make potential future type system changes easier to achieve, let's just remove the type check on TypeVarTuple and ParamSpec bounds.
CPython versions tested on:
3.15
Operating systems tested on:
macOS
Activity
gh-151955: Allow more ParamSpec and TypeVarTuple bounds (#151956)
[3.13] gh-151955: Allow more ParamSpec bounds (#152122)
[3.15] gh-151955: Allow more ParamSpec and TypeVarTuple bounds (GH-15…
[3.14] gh-151955: Allow more ParamSpec bounds (#152121)
🐛 fix(annotations): drop the NoneType bound of an unbound ParamSpec (#…