-
Notifications
You must be signed in to change notification settings - Fork 293
Conformance suite: Minor tweaks to several assertions for better compatibility with ty #2178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
11875d9
652dde5
7b6a5d2
88bf117
9955ae1
d59f132
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,6 @@ | ||
| # Specification: https://typing.readthedocs.io/en/latest/spec/generics.html#scoping-rules-for-type-variables | ||
|
|
||
| from typing import TypeVar, Generic, Iterable, TypeAlias, assert_type | ||
| from typing import TypeVar, Generic, Iterable, TypeAlias, assert_type, Literal | ||
|
|
||
| # > A type variable used in a generic function could be inferred to represent | ||
| # > different types in the same code block. | ||
|
|
@@ -11,8 +11,13 @@ def fun_1(x: T) -> T: # T here | |
| def fun_2(x: T) -> T: # and here could be different | ||
| return x | ||
|
|
||
| assert_type(fun_1(1), int) | ||
| assert_type(fun_2('a'), str) | ||
| # One of these two should pass; either is acceptable: | ||
| assert_type(fun_1(1), int) # E[fun1-int] | ||
| assert_type(fun_1(1), Literal[1]) # E[fun1-int] | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 --
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes, as per https://github.com/python/typing/tree/main/conformance#test-case-syntax:
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. cc @davidhalter - FYI this conformance change turned up what looks like a bug in zuban.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rchen152 Thanks, it looks like something about the nesting causes issues. Will investigate.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I quickly fixed this (on master branch). Zuban inferred essentially an intersection type of I don't think this was necessarily a bug in Zuban, but it's probably easier to work with the conformance tests if I implement it this way.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
|
||
| # One of these two should pass; either is acceptable: | ||
| assert_type(fun_1("a"), str) # E[fun1-str] | ||
| assert_type(fun_1("a"), Literal["a"]) # E[fun1-str] | ||
|
AlexWaygood marked this conversation as resolved.
Outdated
|
||
|
|
||
| # > A type variable used in a method of a generic class that coincides | ||
| # > with one of the variables that parameterize this class is always bound | ||
|
|
@@ -39,8 +44,14 @@ def method(self, x: T, y: S) -> S: | |
| return y | ||
|
|
||
| x: Foo[int] = Foo() | ||
| assert_type(x.method(0, "abc"), str) | ||
| assert_type(x.method(0, b"abc"), bytes) | ||
|
|
||
| # Either of these is acceptable; one of the two should pass: | ||
| assert_type(x.method(0, "abc"), str) # E[method-str] | ||
| assert_type(x.method(0, "abc"), Literal["abc"]) # E[method-str] | ||
|
|
||
| # Either of these is acceptable; one of the two should pass: | ||
| assert_type(x.method(0, b"abc"), bytes) # E[method-bytes] | ||
| assert_type(x.method(0, b"abc"), Literal[b"abc"]) # E[method-bytes] | ||
|
|
||
| # > Unbound type variables should not appear in the bodies of generic functions, | ||
| # > or in the class bodies apart from method definitions. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,7 +4,7 @@ | |
|
|
||
| # Specification: https://peps.python.org/pep-0695/#type-parameter-scopes | ||
|
|
||
| from typing import Callable, Mapping, Sequence, TypeVar, assert_type | ||
| from typing import Callable, Mapping, Literal, Sequence, TypeVar, assert_type | ||
|
|
||
| # > A compiler error or runtime exception is generated if the definition | ||
| # > of an earlier type parameter references a later type parameter even | ||
|
|
@@ -102,23 +102,24 @@ def method3[T](self, x: T): # E | |
| T = int(0) | ||
|
|
||
|
|
||
| class Outer2[T]: | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the assertions in this test ran into issues because ty inferred ty also rejected the |
||
| T = int(1) | ||
|
|
||
| assert_type(T, int) | ||
| def f(a: int, b: str, c: complex): | ||
| class Outer2[T]: | ||
| T = a | ||
|
|
||
| class Inner1: | ||
| T = str("") | ||
| assert_type(T, int) | ||
|
|
||
| assert_type(T, str) | ||
| class Inner1: | ||
| T = b | ||
|
|
||
| def inner_method(self): | ||
| assert_type(T, TypeVar) | ||
| assert_type(T, str) | ||
|
|
||
| def outer_method(self): | ||
| T = 3j | ||
| def inner_method(self): | ||
| assert_type(T, TypeVar) | ||
|
|
||
| assert_type(T, complex) | ||
| def outer_method(self): | ||
| T = c | ||
|
|
||
| def inner_func(): | ||
| assert_type(T, complex) | ||
|
|
||
| def inner_func(): | ||
| assert_type(T, complex) | ||
Uh oh!
There was an error while loading. Please reload this page.