Recently I noticed that the new PEP 604 Union type doesn't collect type variables:

from typing import TypeVar
T = TypeVar('T')

(int | list[T]).__parameters__

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'types.Union' object has no attribute '__parameters__'

Whereas the typing.Union version has __parameters__. Is this behavior intentional?

The downside to this is that things like this don't work:

alias: TypeAlias = int | list[T]
alias[str] # Error!

I agree that this is a bug. `types.Union` is also missing a __getitem__ implementation.

And `typing.Union` supports pickling while `types.Union` doesn't:

>>> pickle.loads(pickle.dumps(int | str))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot pickle 'types.Union' object
>>> pickle.loads(pickle.dumps(Union[int, str]))
typing.Union[int, str]

I don't have a use case for pickling types but someone might.

Let's first see whether the type (int | list[T]) is accepted by static checkers.

IMO introspecting unions should be done by looking at __args__, nothing more.

Should `__getitem__` be implemented for `types.Union`?
I can implement it if no one is working on it.

P.S. mypy currently does not support it:
```
Value of type "types.Union" is not indexable
```

Yurii, thanks for the offer.

We only need to implement __getitem__ if union supports TypeVars. Which
means __parameters__ need to be implemented too (or at least a private
internal implementation of it).

I interpreted Guido's message above as to wait and see if static type
checkers even accept things like int | list[T]. Maybe he meant that if that
syntax isnt valid then theres no point for us to implement it? PEP 604
leaves out how it deals with TypeVars, so adding this behavior may require
us to update the PEP first (which will require approval from others).

Anyways, there's no rush. We probably can't backport this so we have until
the next minor release of Python (3.11 or later) to decide.

I intended for someone to write some test programs and report back here what mypy actually supports and what it doesn't.

mypy does not support __parameters__:

    (venv) ➜  cpython git:(main) cat repro.py 
    from typing import TypeVar
    T = TypeVar('T')

    (int | list[T]).__parameters__
    (venv) ➜  cpython git:(main) mypy --version
    mypy 0.920+dev.cae5d3c8b5f14d0796914aa6a113473ca3ffc38e
    (venv) ➜  cpython git:(main) python --version
    Python 3.11.0a0
    (venv) ➜  cpython git:(main) mypy repro.py 
    repro.py:4: error: "types.Union" has no attribute "__parameters__"
    Found 1 error in 1 file (checked 1 source file)
    (venv) ➜  cpython git:(main)


mypy also does not support __getitem__

    (venv) ➜  cpython git:(main) cat repro.py 
    from typing import TypeVar
    T = TypeVar('T')

    (int | list[T]).__getitem__
    (venv) ➜  cpython git:(main) mypy --version
    ./mypy 0.920+dev.cae5d3c8b5f14d0796914aa6a113473ca3ffc38e
    (venv) ➜  cpython git:(main) python --version
    Python 3.11.0a0
    (venv) ➜  cpython git:(main) mypy repro.py 
    repro.py:4: error: Value of type "types.Union" is not indexable
    Found 1 error in 1 file (checked 1 source file)
    (venv) ➜  cpython git:(main)

Mypy is definitely not going to support direct access to `__parameters__`; what Guido is referring to is whether usage of types.Union that would require `__parameters__` at runtime is accepted by mypy.

For example, this:

from typing import TypeVar

T = TypeVar("T")

Alias = int | list[T]

def f(x: Alias[str]) -> None:
    pass

But this produces `main.py:7: error: Variable "main.Alias" is not valid as a type`: mypy doesn't even recognize `|` as a type yet.

I'd rather not focus too much though on what mypy does; it is one of many type checkers by now and does not tend to be the quickest in adding support for new features.

Pyright does handle the file above as I'd expect, for what it's worth.

So I guess to expand on Jelle's example, Alias[str] should return (int |
list[str]), right? That makes sense since that's how Union works.

I'd also be OK with returning a `types.GenericAlias(int | list[T], str)`, which might be simpler. It doesn't matter for static type checkers, and runtime type checkers can extract what they need anyway.

I don't think we need the types.GenericAlias(int | list[T], str)
workaround. GenericAlias already has code for extracting __parameters__ and
implementing __getitem__. Someone would need to refactor and reuse them for
Union too. That should be enough to trick GenericAlias to treat Union as
another GenericAlias(I don't remember if it checks for __origin__ as well)
and cover other edge cases as well.

@Yurii do you still plan to take this? If not, I'll start working on
something later today.

@Ken I will pick up this issue, thanks for asking.

It also lacks the __module__ attribute, causing it to be unusable in PEP 593 typing.Annotated types:

from typing import Annotated
x: Annotated[int | str, 'test']

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ruben/.pyenv/versions/3.10.0b3/lib/python3.10/typing.py", line 298, in inner
    return cached(*args, **kwds)
  File "/Users/ruben/.pyenv/versions/3.10.0b3/lib/python3.10/typing.py", line 1594, in __class_getitem__
    return _AnnotatedAlias(origin, metadata)
  File "/Users/ruben/.pyenv/versions/3.10.0b3/lib/python3.10/typing.py", line 1520, in __init__
    super().__init__(origin, origin)
  File "/Users/ruben/.pyenv/versions/3.10.0b3/lib/python3.10/typing.py", line 976, in __init__
    self.__module__ = origin.__module__
AttributeError: 'types.Union' object has no attribute '__module__'. Did you mean: '__reduce__'?

New changeset c45fa1a5d9b419cf13ad4b5a7cb453956495b83e by Yurii Karabas in branch 'main':
bpo-44490: Add __parameters__ and __getitem__ to types.Union (GH-26980)
https://github.com/python/cpython/commit/c45fa1a5d9b419cf13ad4b5a7cb453956495b83e