"Union requires two or more type arguments" reported for non-type annotation usage of Union (e.g. introspection)

[ghost]

Environment data

• Language Server version: v2021.10.3
• OS and version: macOS 11.6
• Python version: 3.9.6

Expected behaviour

typing.Union with no subscript is valid when it is used in certain situations other than type annotation, such as for runtime introspection, for example, using typing.get_origin:

from typing import Union, get_origin

union_type = Union[int, float, bool]
assert get_origin(union_type) is Union  # is a union type
# get_origin will return the `Union` object itself

In such use cases, Pylance should not report issues.

Actual behaviour

Pylance reports "Union requires two or more type arguments."

This seems to be introduced in the latest 2021.10.3 (October 27) version, in this feature:

Enhancement: Added check for Union when only one type argument is provided and it is not an unpacked variadic type variable.

[ghost]

The same issue appears with typing.Generic as well.

[erictraut]

The issue with Union has already been fixed in pyright. (See microsoft/pyright#2499). I'll file a separate issue for Generic.

[heejaechang]

fixed in 2021.11.0

[coady]

This is still reported when Union[...] is used with a non-literal tuple, which is valid.

tup = int, float
Union[tup]  # Union requires two or more type arguments
Union[int]  # same

[erictraut]

which is valid

This isn't valid. It doesn't crash at runtime, but Union is a special form that's part of the type system, and type checkers like pyright and mypy apply additional rules about what is is valid and what is not for these special forms. Tuples and tuple expressions are also not allowed here. Mypy generates the same error if you try to use a tuple here

I'll also note that the use of Union is no longer recommended. The modern way to express a union type within a type annotation is int | float.

[hellozyemlya]

which is valid

This isn't valid. It doesn't crash at runtime, but Union is a special form that's part of the type system, and type checkers like pyright and mypy apply additional rules about what is is valid and what is not for these special forms. Tuples and tuple expressions are also not allowed here. Mypy generates the same error if you try to use a tuple here

I'll also note that the use of Union is no longer recommended. The modern way to express a union type within a type annotation is int | float.

and what is a valid way to create union out of tuple of arguments?

[erictraut]

and what is a valid way to create union out of tuple of arguments?

There isn't a valid way to do this in the Python type system. Could you describe your use case in more detail? You can use a type alias that refers to a union to define another union, if that helps.

[coady]

Tuples and tuple expressions are also not allowed here. Mypy generates the same error if you try to use a tuple here

There isn't a valid way to do this in the Python type system. Could you describe your use case in more detail?

My use case is the same as the original: runtime introspection. Mypy doesn't error if Union[a_tuple] is used in plain untyped code.

[hellozyemlya]

and what is a valid way to create union out of tuple of arguments?

There isn't a valid way to do this in the Python type system. Could you describe your use case in more detail? You can use a type alias that refers to a union to define another union, if that helps.

As mentioned above - runtime introspection. My primary goal is "un-Optional" type. I check if type is Union\UnionType, and ensure that there is one last NoneType in get_args(my_type).

I worked-around that by following code:

    result = None
    for t in get_args(optional_type)[:-1]:
        if result is None:
            result = t
        else:
            result = result | t

seems to be working fine, and mypy & pyright are happy about that.

ps: Union and UnionType(str | int gives UnionType) seems to be different when comes to get_origin, still Union[str, int] == str | int equals True
pps: for some reason can't import UnionType(on homebrew 3.11 python) from typing, but type(str | int) resolves to proper type.