Is a type variable with repeated constraints valid?

[bzoracler]

The spec currently says:

There should be at least two constraints, if any; specifying a single constraint is disallowed.

To my surprise, no type-checker seems to reject this, and allows usage of this type variable:

from typing import TypeVar
type INT = int
T = TypeVar("T", int, int, INT)

def f(arg: T, /) -> T:
    return arg

reveal_type(f(True))  # builtins.int

This was found when changing one of the constraints from a NewType("MyInt", int) to a TypeAliasType("MyInt", int).

[lul-cas]

So, at runtime a single constraint is rejected (TypeVar("T", int) → TypeError), but repeated ones are fine, like:

type INT = int
T = TypeVar("T", int, int, INT)  # ths works; __constraints__ == (int, int, INT)

Type checkers accept it too. Duplicate constraints basically collapse to the same type, so "T" behaves like its constrained to int.

On f(True) → int: bool is a subclass of int in Python, so checkers treat True as compatible with an int constraint.

The spec says you need at least two constraints and cant have just one. int, int, INT satisfies that literally, but its really the same as a single int constraint, which the spec says isnt allowed. This looks more like a spec edge case than a checker bug.

Maybe this just needs a typing spec clarification. It works today, both at runtime and in type checkers, but I dont think that this is a checker bug. Prolly more of a edge case where the spec doenst say whether repeated || equivalent constraints should count separately

[nazeeh111]

I reproduced the constructor on Python 3.14.7. It accepts the declaration and preserves the supplied entries in T.__constraints__ as (int, int, INT). At runtime, INT is a distinct TypeAliasType object (it is not int by identity or equality), with INT.__value__ is int. So the runtime constructor neither deduplicates the entries nor resolves the alias before storing them. This confirms runtime acceptance, but does not by itself establish how a checker should compare their effective types.

The current spec says there must be at least two constraints; it does not say they must be pairwise distinct or define whether aliases are expanded before counting. On the text as written, this declaration has three supplied constraints, while the semantic question raised here remains underspecified. If the intended rule is “at least two distinct effective types,” the spec would need to say how duplicate arguments, aliases, and NewType are treated. The existing checker behavior therefore looks consistent with the literal wording; I would treat the remaining gap as a spec clarification, not a checker bug. https://typing.python.org/en/latest/spec/generics.html#type-variables

I ran the runtime check only; I have not tested current mypy or Pyright versions. Prepared with Codex assistance.