[conformance] Add examples that require bidi inference of list literals after specialization inference

[dcreager]

The conformance suite currently contains the following example:

typing/conformance/tests/constructors_callable.py

Lines 178 to 186 in 94514b1

	class Class8(Generic[T]):
	def __new__(cls, x: list[T], y: list[T]) -> Self:
	return super().__new__(cls)
	r8 = accepts_callable(Class8)
	reveal_type(r8) # `def [T] (x: list[T], y: list[T]) -> Class8[T]`
	assert_type(r8([""], [""]), Class8[str])
	r8([1], [""]) # E

The important point is that r8 is a generic callable. It has the following signature:

[T](x: list[T], y: list[T]) -> Class8[T]

Previously, the last line of this example would require that if you pass in list literals of different types, it should be a type inference error. However, the union of the two lists' respective element types is a valid solution — in this case, T = int | str.

I've updated these examples so that it's not an error if they succeed. We don't require the more difficult inference result. (This example holds for a simpler generic function, so most of the new tests are in generics_basic.py.)

I've also added additional tests for examples where there is genuinely no valid specialization: when one of the arguments is not a list at all, and where the typevar is bounded and the argument is a list that cannot possibly satisfy the upper bound.

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[JelleZijlstra]

I agree with changing this, but the proposal to require type checkers to infer the union also doesn't feel right. This test isn't about testing precise inference behaviors, it's about testing class constructors. Type inference behavior in cases like this test isn't specified precisely, so we shouldn't force a specific behavior in the conformance suite.

The same behavior is observable in a simpler function:

def f[T](x: list[T], y: list[T]):
    pass

f([1], ["x"])

is currently rejected by all type checkers in multiplay.

[dcreager]

I agree with changing this, but the proposal to require type checkers to infer the union also doesn't feel right. This test isn't about testing precise inference behaviors, it's about testing class constructors. Type inference behavior in cases like this test isn't specified precisely, so we shouldn't force a specific behavior in the conformance suite.

I moved most of the tests over to generics_basic, and made the main example from the PR body E? so that we do not require the specific inference result.

[dcreager]

(Do you typically squash-merge? If not do you prefer that I merge the commits on this branch to make a single clean atomic commit?)

[carljm]

We do usually squash merge, I don't think the branch commit history matters at all.

[carljm]

Going ahead and merging this -- seem uncontroversial to allow this inference, but not require it.