Strange behavior when one of the constraints of a generic class's type variable is typing.Any?

[A-Paint-Brush]

I'm not entirely sure if this is a bug, but I've noticed a strange behavior as the title says. Consider the following example:

from typing import Any, reveal_type


class MyClass[T: (int, float, Any)]:
    def __init__(self, name: str, attr: T, attrs: list[T]) -> None:
        self.name: str = name
        self.attr: T = attr
        self.attrs: list[T] = attrs


def test_int(obj: MyClass[int]) -> None:
    reveal_type(obj)
    reveal_type(obj.name)
    reveal_type(obj.attr)
    reveal_type(obj.attrs)


def test_float(obj: MyClass[float]) -> None:
    reveal_type(obj)
    reveal_type(obj.name)
    reveal_type(obj.attr)
    reveal_type(obj.attrs)


def test_any(obj: MyClass[Any]) -> None:
    reveal_type(obj)
    reveal_type(obj.name)
    reveal_type(obj.attr)
    reveal_type(obj.attrs)

This defines a generic class with one type variable that has 3 constraints: int, float, and Any. Here's what Pyright outputs when I run it on the command-line (with full file paths removed for brevity):

c:\...\file.py
  c:\...\file.py:12:17 - information: Type of "obj" is "MyClass[Any]"
  c:\...\file.py:13:17 - information: Type of "obj.name" is "str"
  c:\...\file.py:14:17 - information: Type of "obj.attr" is "Any"
  c:\...\file.py:15:17 - information: Type of "obj.attrs" is "list[Any]"
  c:\...\file.py:19:17 - information: Type of "obj" is "MyClass[Any]"
  c:\...\file.py:20:17 - information: Type of "obj.name" is "str"
  c:\...\file.py:21:17 - information: Type of "obj.attr" is "Any"
  c:\...\file.py:22:17 - information: Type of "obj.attrs" is "list[Any]"
  c:\...\file.py:26:17 - information: Type of "obj" is "MyClass[Any]"
  c:\...\file.py:27:17 - information: Type of "obj.name" is "str"
  c:\...\file.py:28:17 - information: Type of "obj.attr" is "Any"
  c:\...\file.py:29:17 - information: Type of "obj.attrs" is "list[Any]"
0 errors, 0 warnings, 12 informations 

The output is also the same when using the Pyright playground instead of running locally (playground link). As the output shows, it now treats the TypeVar as having the type Any no matter what type was actually pass to it in the parameter annotations of the test functions. If I change MyClass to remove the Any in the constraints (like class MyClass[T: (int, float)]:) and remove the test_any function, then the output is as expected:

c:\...\file.py
  c:\...\file.py:12:17 - information: Type of "obj" is "MyClass[int]"
  c:\...\file.py:13:17 - information: Type of "obj.name" is "str"
  c:\...\file.py:14:17 - information: Type of "obj.attr" is "int"
  c:\...\file.py:15:17 - information: Type of "obj.attrs" is "list[int]"
  c:\...\file.py:19:17 - information: Type of "obj" is "MyClass[float]"
  c:\...\file.py:20:17 - information: Type of "obj.name" is "str"
  c:\...\file.py:21:17 - information: Type of "obj.attr" is "float"
  c:\...\file.py:22:17 - information: Type of "obj.attrs" is "list[float]"
0 errors, 0 warnings, 8 informations 

If I type-check the original code using MyPy instead, it outputs what I expect (playground link):

file.py:12: note: Revealed type is "file.MyClass[builtins.int]"
file.py:13: note: Revealed type is "builtins.str"
file.py:14: note: Revealed type is "builtins.int"
file.py:15: note: Revealed type is "builtins.list[builtins.int]"
file.py:19: note: Revealed type is "file.MyClass[builtins.float]"
file.py:20: note: Revealed type is "builtins.str"
file.py:21: note: Revealed type is "builtins.float"
file.py:22: note: Revealed type is "builtins.list[builtins.float]"
file.py:26: note: Revealed type is "file.MyClass[Any]"
file.py:27: note: Revealed type is "builtins.str"
file.py:28: note: Revealed type is "Any"
file.py:29: note: Revealed type is "builtins.list[Any]"
Success: no issues found in 1 source file

Is this a bug in Pyright or is it intentional?

[erictraut]

In this code sample, you're using a value-constrained type variable. The behaviors of value-constrained type variables are woefully underspecified in the Python typing spec. I generally recommend against using them if at all possible. They are not found in any other language or type system — and for good reason. It's unfortunate that they were added to the Python type system, and it's not clear whether we'll ever be able to fully specify them in a way that composes well with other type features.

One aspect of value-constrained type variables that is unspecified is what a type checker should do when two or more of the constraint types are overlapping. In your example, all three constraint types are overlapping. The float type is a supertype of int (which means that the set of values represented by int is a proper subset of the set of values represented by float). And all types overlap Any. Constraints that overlap should arguably be flagged as an error by a type checker. It's because of these overlapping constraints that you're seeing the strange behavior above. Value-constrained type variables were not designed to be used with overlapping constraints.

I can't tell from your code sample what problem you're trying to solve here, but if you're able to use a standard type variable — or a type variable with an upper bound of float, you will be on much firmer ground. The behaviors for normal type variables are well specified.

In summary, this isn't a bug in pyright, nor is it a bug in mypy. The behavior you're seeing is because you're using a poorly-specified feature of the type system in a way that it wasn't designed to be used.

[A-Paint-Brush]

Oh, I see. I didn't know you weren't supposed to use overlapping types in a type var, I'll fix that in my real code now (the sample I gave was just to demonstrate the issue and not the actual code). Thanks for the reply.