Unexpected behaviour in generic unions when using a bound type var

[FasterSpeeding]

Describe the bug

Pyright expects generic unions which are based on a bound type variable to be given a type which subclasses the bound rather than an instance which subclasses the bound. This breaks from normal/expected behaviour where it should expect an instance unless typing.Type/type is explicitly used.

As a note, I also observed unexpected behaviour when wrapping the type variable in Type while declaring the Union with typing.Union[int, Type[FooT]] changing pyright's behaviour so that it now passes bat: FooIsh[Bar] = 42 but returns an error on bat2: FooIsh[typing.Type[Bar]] = 42.

To Reproduce

Check the following example code with pyright and watch it produce the following unexpected error

C:\Users\Lucina\PycharmProjects\hikari\test.py
  C:\Users\Lucina\PycharmProjects\hikari\test.py:19:6 - error: Could not specialize type "FooIsh[Type[FooT@FooIsh]]"
    Type "Bar" is incompatible with bound type "Type[Foo]" for type variable "FooT@FooIsh"
      Type "Bar" cannot be assigned to type "Type[Foo]"
1 error, 0 warnings, 0 infos

Expected behavior

Pyright should allow bat: FooIsh[Bar] = 42 since Bar subclasses the defined bound and error on bat2: FooIsh[typing.Type[Bar]] = 42 since the union isn't defined as taking Type[FooT].

Screenshots or Code

import typing


class Foo:
    def __int__(self) -> int:
        return 0


FooT = typing.TypeVar("FooT", bound=Foo)
FooIsh = typing.Union[int, FooT]


class Bar(Foo):
    def __int__(self) -> int:
        return super().__int__() + 1


# This should be valid but Pyright complains about it.
bat: FooIsh[Bar] = 42
# This shouldn't be valid but Pyright accepts it.
bat2: FooIsh[typing.Type[Bar]] = 42

VS Code extension or command-line
Running pyright 1.1.138 on Windows 10 Pro (21364.1000)

[erictraut]

FooIsh is a type alias, which means that it should refer to classes, not class instances.

# Correct usage of type alias
TypeAlias1 = int
TypeAlias2 = Union[int, str]
TypeAlias3 = Foo
TypeAlias4 = Type[FooT]

# Incorrect usage of type alias
TypeAlias5 = 3
TypeAlias6 = Union[int, "hi"]
TypeAlias7 = Foo()
TypeAlias8 = FooT

If you change your type alias definition to the following, it will work as you expect:

FooIsh = typing.Union[int, Type[FooT]]

[FasterSpeeding]

Mind if I ask for some clarification on what makes this case different from something like

MapT = typing.MutableMapping[int, FooT]
di: MapT[Bar] = {123: Bar()}

where unlike in FooIsh = typing.Union[int, typing.Type[FooT]] FooT isn't wrapped in Type to indicate that we want an instance(?) of which ever type that's valid for FooT is provided?

[erictraut]

What makes this different is that FooT is being used as a type argument for MutableMapping.

Yes, this can be confusing. The Python type specifications (PEP 484, etc.) are not very clear on when a symbol should be treated as a class or a class instance, and it has taken me a while to work out all of the rules that pyright uses. The meaning of a symbol varies by the context in which it is used. Consider the following:

# In the context of a type annotation, "int" means "an instance of the class int"
a: int = 3

# In the context of a type alias, "int" means "the class int"
b = int

# This is another type alias, so "int" still means "the class int"
c = Union[int, str]

# In the context of a type argument, it's interpreted as an instance (this is a "list of int instances")
d: List[int] = []

# This is referring to a list containing an int class, not an int instance
e = [int]

[JelleZijlstra]

For what it's worth, the pyright behavior also seems incorrect to me. I would expect Union[int, FooT] to mean either an int or an instance of Foo or a subclass, and Union[int, Type[FooT]] to mean either an int or a class object that is a subclass of Foo. That matches what mypy does, although mypy seems to have a different bug where it ignores the typevar bound.

[erictraut]

Mypy seems not to care either way. It allows both of the following and appears to treat them the same:

FooIsh = Union[int, FooT]
FooIsh = Union[int, Type[FooT]]

I would think that one of these is correct and the other is not.

Pyright used to accept both as well, but I needed to get more strict about this distinction when I added support for recursive type aliases, a feature that mypy does not support.

[JelleZijlstra]

Mypy does not treat them the same:

import typing

FooT = typing.TypeVar("FooT", bound=str)
FooIsh = typing.Union[int, typing.Type[FooT]]

bat2: FooIsh[float] = 1.0  # E: Incompatible types in assignment (expression has type "float", variable has type "Union[int, Type[float]]")

(But as noted it ignores the bound, which seems like a bug.)

[erictraut]

Ah, I stand corrected. You're right — it does treat them differently.

It would be best if pyright and mypy had consistent behavior here. I will investigate and explore whether I can reconcile this behavior with the recursive type alias support.

[erictraut]

This will be fixed in the next release of pyright. With the fix in place, it now accepts this:

bat: FooIsh[Bar] = 42

And it properly generates an error here:

bat2: FooIsh[typing.Type[Bar]] = 42

Interestingly, mypy accepts both of these without generating an error.