Add tests for Final/Literal interaction - #2352
Conversation
It means that if the automated conformance fails, it is your responsibility to analyze the nature of the gap for that type checker, and decide whether |
| # Specification: https://typing.readthedocs.io/en/latest/spec/qualifiers.html#id1 | ||
|
|
||
| ID1: Final[int] = 1 | ||
| assert_type(ID1, Literal[int]) |
There was a problem hiding this comment.
Literal[int] is not a valid type expression (and thus every type checker correctly errors on it). Same with Literal[float] below.
Did you mean to assert the type is just int? If so, I don't think that's an assertion supported by the spec. https://typing.python.org/en/latest/spec/literal.html#interactions-with-final explicitly says that in this exact scenario, an inference of either int or Literal[1] is fine.
There was a problem hiding this comment.
Interesting, another contradiction in the spec.
|
What is your intention for this PR vs #2353 ? I think it would be simpler and preferable to just have one combined PR that modifies both the spec text and the conformance suite, rather than two separate PRs. |
srittau
added
the
topic: conformance tests
Sure, I can combine them if you prefer. Considering that both are more or less independent (since the are only refactorings/documentation of the status quo) I thought it would be easier to review separately. |
|
I don't have strong feelings; if you prefer to separate them, that's fine. I would personally find it easier to review them together; it makes it easier to validate that we have the right tests for the clarified spec text. |
|
Will merge when I get home. |
2 participants
This is my first time changing the conformance tests, did I do it correctly? What does "conformant is required when conformance_automated is 'Fail'" mean?
Also cf. #2351. If that issue and this PR is accepted I would like to add quotes from the (changed) spec to the tests before merging this.