Skip to content

TypeVarTuple/ParamSpec bounds are checked too aggressively #151955

Description

@JelleZijlstra

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

Linked PRs

Metadata

Metadata

Assignees

Labels

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions