[conformance] Add examples that require bidi inference of list literals after specialization inference#2300
[conformance] Add examples that require bidi inference of list literals after specialization inference#2300dcreager wants to merge 2 commits into
Conversation
…ls after specialization inference
|
All commit authors signed the Contributor License Agreement. |
|
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. |
I moved most of the tests over to |
The conformance suite currently contains the following example:
typing/conformance/tests/constructors_callable.py
Lines 178 to 186 in 94514b1
The important point is that
r8is a generic callable. (There isn't a syntax that lets us easily spell a generic callable type usingCallable, so we had to jump through the small hoop ofaccept_callableto obtain it.) It has the following signature: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 they are expected to succeed.
Open question: I also had considered marking them as
E?, since it does require a more complex specialization inference process that we might not want to mandate.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.