Merge 'types.UnionType' with `typing._UnionGenericAlias`, not `typing.Union`

[serhiy-storchaka]

Bug report

I think #105499 was a mistake. types.UnionType was intentionally named so to avoid confusion with typing.Union (see #88895). types.UnionType should not be subscriptable because it is not generic type (and if it was a generic type, subscription would have different semantic than for typing.Union). types.UnionType corresponds to typing._UnionGenericAlias, not typing.Union (see #89581 (comment)).

So we should restore typing.Union, make typing._UnionGenericAlias an alias of types.UnionType, and make types.UnionType non-subscriptable again.

Linked PRs

• gh-137065: Unmerge types.UnionType and typing.Union #137069
• gh-137065: Revert "gh-105499: Merge typing.Union and types.UnionType (#105511)" #138967

[serhiy-storchaka]

#137069 restores typing.Union, subscribing which returns now a types.UnionType instance. types.UnionType is no longer subscripable. typing._UnionGenericAlias was left as it was -- unused and deprecated.

A private function is used to create types.UnionType instances. This is a temporary solution. The public ways are int | str and typing.Union[int, str]. We may add other public way in future (make types.UnionType callable or add a class method), but this needs further investigation.

[JelleZijlstra]

I don't think there was a mistake and I don't see a case for changing the behavior yet again in the RC phase. What concrete problems does the current behavior cause?

[serhiy-storchaka]

1. types.UnionType should not be subscriptable, because it is not a generic type. There is a general rule to only use __class_getitem__ for parametrization of generic classes. It was its purpose.
2. typing.Union should not be a class. Initially the typing types were implemented as classes, but this caused many issues, so they all were reimplemented as non-classes.

I am sorry that I noticed this change so late, but it will be much more difficult to unmerge types.UnionType and typing.Union after release.

[JelleZijlstra]

Those are not concrete problems.

I feel this mistake here was that types.UnionType was added as a separate public type in 3.10. Things should have been implemented the way they are now in 3.14 in the first place, so introspection code doesn't always have to deal with two kinds of unions. Fortunately, we were able to make the change now with a minimum of compatibility implications.