Conformance suite: Minor tweaks to several assertions for better compatibility with ty#2178
Conformance suite: Minor tweaks to several assertions for better compatibility with ty#2178AlexWaygood wants to merge 6 commits intomainfrom
Conversation
…atibility with ty
AlexWaygood
added
the
topic: conformance tests
| T = int(0) | ||
|
|
||
|
|
||
| class Outer2[T]: |
There was a problem hiding this comment.
the assertions in this test ran into issues because ty inferred T as having type Literal[""] where T = str("").
ty also rejected the assert_type(T, complex) call lower down after the T = 3j assignment, because we view complex in a type expression as immediately expanding to the union int | float | complex, and the second argument to assert_type takes a type expression -- but complex (the type inferred for T) is not equivalent to int | float | complex.
|
I'll revert the changes to the defaults-related tests for now, since they're clearly a bit more problematic than the others, but this PR was intended to bundle together several relatively uncontroversial changes |
| assert_type(generator30, Callable[[], AsyncIterator[int]]) | ||
| async def uses_generator30() -> None: | ||
| async for x in generator30(): | ||
| assert_type(x, int) |
There was a problem hiding this comment.
ty infers a "function-literal" type for generator30, not a Callable type. A function-literal type is more precise than a Callable type: it retains, for example, the information that generator30 is an instance of types.FunctionType, which is not true for all arbitrary Callable types.
I don't believe the spec states anywhere that type checkers must infer a Callable type for function objects (only that functions must be considered to inhabit Callable types), so I think this change is appropriate.
I tried doing just assert_type(generator30(), AsyncIterator[int]), but then zuban (reasonably) complained that the result of generator30() was never awaited, which wasn't relevant to what the test was trying to assert.
| assert_type(fun_1(1), int) # E[fun1-int] | ||
| assert_type(fun_1(1), Literal[1]) # E[fun1-int] |
There was a problem hiding this comment.
How does the conformance checker handle it if there's an error on both of these lines? It's the intent of the test that that should be considered non-conforming.
There was a problem hiding this comment.
I believe a tagged error like this is still non-optional: an error must be emitted on at least one of these lines. This seems to be reflected by the fact that zuban is no longer considered conformant on this PR branch, if you look at the changes to the reported results -- it apparently doesn't emit an error on either of these lines. (That seems like a bug in zuban to me -- int and Literal[1] are not equivalent types, so fun_1(1) cannot be equivalent to both int and Literal[1].)
There was a problem hiding this comment.
yes, as per https://github.com/python/typing/tree/main/conformance#test-case-syntax:
# E[tag], wheretagis an arbitrary string: must appear multiple times in a file with the same tag. Exactly one line with this tag must raise an error.
There was a problem hiding this comment.
cc @davidhalter - FYI this conformance change turned up what looks like a bug in zuban.
Co-authored-by: Rebecca Chen <rchen152@gmail.com>
4 participants
This PR makes several tweaks to the conformance suite to resolve issues where ty would appear to be failing assertions the conformance suite makes. In reality, all of the locations edited in this PR appear to be causing ty failures due to the fact that the suite was making overly specific assertions that made undue assumptions.
These are all minor changes that do not change the intent of the tests, so I've bundled them together.