gh-140348: Fix using | on unusual objects plus Unions

[JelleZijlstra]

This restores the 3.13 behavior where Union[A, B] | ... was almost always allowed, rejecting only things that typing._type_check rejects.

It also necessarily means that something like int | str | "float" now works. And if a third-party type implements __ror__ on union objects and does something other than create a union, it may no longer work.

• Issue: Python 3.14 regression in supported types for | syntax for typing.Union and strings #140348

[Fidget-Spinner]

I havent heavily been involved in unionobject.c or genericaliasobject.c in about 4 years. But from what I recall, LGTM.

[efimov-mikhail]

CI is red, this PR breaks some tests.
I've prepared slighly changed variant of this:
https://github.com/efimov-mikhail/cpython/tree/issue-140383-union-nb-or

[JelleZijlstra]

Oops, pushed a new version that does not impact other types.

[efimov-mikhail]

Is it okay that now we have two variants of __or__ method? For example, will GenericAlias and str objects work together as expected?

[JelleZijlstra]

They don't, and maybe they should, but the behavior is the same in 3.13 and 3.14, so it's not part of the current issue. This PR focuses only on fixing the regression in 3.14.

$ uvx python3.13 -c 'list[int] | "str"'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    list[int] | "str"
    ~~~~~~~~~~^~~~~~~
TypeError: unsupported operand type(s) for |: 'types.GenericAlias' and 'str'
$ uvx python3.14 -c 'list[int] | "str"'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    list[int] | "str"
    ~~~~~~~~~~^~~~~~~
TypeError: unsupported operand type(s) for |: 'types.GenericAlias' and 'str'