gh-91603: Speed up UnionType instantiation

[uriyyo]

#91603

Summary

Remove types.UnionType.__args__ recreation (flatten_args and dedup_and_flatten_args ).
Use the fact that in the case when union with another types.UnionType that union has deduplicated normalized __args__.

As a result complexity from O((M+N)^2) was reduced to O(M*N), where M - length of left union args, N - length of right union args.

Benchmarks:

Benchmark	this	main
int | float	67.5 ns	121 ns: 1.80x slower
int | (list | float)	153 ns	250 ns: 1.64x slower
(int | float) | list	142 ns	238 ns: 1.67x slower
(int | float) | (list | set)	253 ns	411 ns: 1.63x slower
(float | set) | int | int | (float | list)	450 ns	687 ns: 1.53x slower
float | set | int | int | float | list	416 ns	750 ns: 1.80x slower
Geometric mean	(ref)	1.67x slower

For big unions:

Benchmark	this	main
bool | int | float | complex | str | bytes | bytearray | list | set | frozenset | dict | range | property | classmethod | staticmethod | Exception	1.38 us	4.08 us: 2.96x slower

[JelleZijlstra]

Thanks, this overall makes sense to me, but I found a few style issues and one bigger problem.

[JelleZijlstra]

We still need this logic for the callsite in union_getitem.

Consider this case:

>>> from typing import TypeVar
>>> T = TypeVar("T")
>>> (list[T] | list[int])
list[~T] | list[int]
>>> (list[T] | list[int])[int]
list[int]

If I'm reading your code correctly, it would no longer deduplicate the two members. It would be good to also add a test case based on this example.

We should probably put the deduping logic directly in union_getitem.

[uriyyo]

@JelleZijlstra Actually, we don't need it, as far as such case already handled by tests:

cpython/Lib/test/test_types.py

Line 823 in 1cd8c29

self.assertEqual((list[T] | list[S])[int, int], list[int])

That's because after parameter substitution new UnionType is recreated by reducing newargs using bitwise or operator:

cpython/Objects/unionobject.c

Lines 380 to 388 in 1cd8c29

	res = PyTuple_GET_ITEM(newargs, 0);
	Py_INCREF(res);
	for (Py_ssize_t iarg = 1; iarg < nargs; iarg++) {
	PyObject *arg = PyTuple_GET_ITEM(newargs, iarg);
	Py_SETREF(res, PyNumber_Or(res, arg));
	if (res == NULL) {
	break;
	}
	}

[JelleZijlstra]

Oh good catch! That seems a bit inefficient too, but we don't need to fix that in this PR; in any case it's probably a less performance-critical path.

[serhiy-storchaka]

Some nitpicks. Did not review the code deeply yet.

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[uriyyo]

I have made the requested changes; please review again

[bedevere-bot]

Thanks for making the requested changes!

@JelleZijlstra, @serhiy-storchaka: please review the changes made to this pull request.

[Fidget-Spinner]

LGTM in general, I just have one question.

[serhiy-storchaka]

Mostly LGTM, except _PyTuple_Resize and some formatting.

But the code can be much smaller. I have refactored it in #91955.

[serhiy-storchaka]

LGTM.

Although I prefer #91955, which is simpler. 😉

[uriyyo]

Closed because #91955 merged