Repository navigation
New conformance tag '# E[tag!]' to require at least one success - #2354
srittau wants to merge 8 commits into
Conversation
Sorry, something went wrong.
|
I don't mind this, but just so you know: I generally just tried to work around this by not using int in these scenarios and using str literals instead, which don't have the promotion issues. In your specific case I might have used: bare3: Final = [1] # infer bare3 as Final[list[int]] I don't think that the promotion details matter for readers of the spec. |
Sorry, something went wrong.
carljm
left a comment
There was a problem hiding this comment.
This seems fine to me as a tool to have, though like @davidhalter I suspect that there is a better way to address the motivating case (we should always avoid using float as part of conformance suite examples, unless those examples are explicitly about the int/float special case) -- and if that leaves us with no use case for this, then it probably doesn't make sense to add it now.
Sorry, something went wrong.
| * `# E[tag]`, where `tag` is an arbitrary string: must appear multiple times in a file with the same tag. | ||
| Exactly one line with this tag must raise an error. | ||
| * `# E[tag+]`: like `# E[tag]`, but errors may be raised on multiple lines. | ||
| * `# E[tag!]`: like `# E[tag]`, but at least one line must not raise an error. |
There was a problem hiding this comment.
We should say explicitly here that zero errors also pass.
Sorry, something went wrong.
| ]: | ||
| """Return the line numbers where type checkers are expected to produce an error. | ||
|
|
||
| The return value is a tuple of two dictionaries: |
There was a problem hiding this comment.
This docstring needs updating.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm also thinking about replacing the second tuple item with either a string literal or an enum "single", "multiple", "require-success". This would make a cleaner API and make it more obvious that these three options are basically mutually exclusive. What do you think?
Sorry, something went wrong.
There was a problem hiding this comment.
Oh sorry I accidentally made a separate comment instead of replying here. If there are really just three supported/useful options, then I think an enum would be better than two booleans. (Better than using strings, too.)
Sorry, something went wrong.
There was a problem hiding this comment.
I've introduced the enum, extracted the logic that makes a decision based on this enum, and simplified the logic so that it should be obvious what's going on. The output doesn't change, indicating that the logic is (still) correct.
Sorry, something went wrong.
- Introduce an `ErrorMultiplicity` enum and return it from `get_expected_errors()`. - Extract `determine_group_error()` from `diff_expected_errors()` and simplify logic. - Rerun black on `main.py`.
Extracted from #2353.
Necessary for pyrefly, which accepts both assert_type(X, float) and assert_type(X, float | int), which other type checkers only accept either.
Not super happy with the syntax, any other suggestions welcome.