GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — New conformance tag '# E[tag!]' to require at least one success by srittau · Pull Request #2354 · python/typing

Conversation

@srittau

@srittau srittau commented Sep 1, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Collaborator

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.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@srittau
New conformance tag '# E[tag!]' to require at least one success
cbaaa37
@davidhalter

davidhalter commented Sep 1, 2026

Copy link
Copy Markdown
Collaborator

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.
carljm reacted with thumbs up emoji
All reactions
  • 👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
carljm
carljm approved these changes Sep 1, 2026
View reviewed changes

@carljm carljm left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread conformance/README.md Outdated
* `# 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.

@carljm carljm Sep 1, 2026

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should say explicitly here that zero errors also pass.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread conformance/src/main.py
]:
"""Return the line numbers where type checkers are expected to produce an error.

The return value is a tuple of two dictionaries:

@carljm carljm Sep 1, 2026

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This docstring needs updating.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions

@srittau srittau Sep 2, 2026

Copy link
Copy Markdown
Collaborator Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Uh oh!

There was an error while loading. Please reload this page.
All reactions

@carljm carljm Sep 2, 2026

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Uh oh!

There was an error while loading. Please reload this page.
All reactions

@srittau srittau Sep 2, 2026

Copy link
Copy Markdown
Collaborator Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Uh oh!

There was an error while loading. Please reload this page.
carljm reacted with thumbs up emoji
All reactions
  • 👍 1 reaction
srittau and others added 8 commits September 2, 2026 13:26
@srittau
Extend description per review
ca6185f
@srittau
Update docstring
8e71a2e
@srittau
Refactor grouped error detection
64624cb 
-  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`.
@srittau
Revert unrelated formatting changes
7f7f565
@srittau
Remove unnecessary type annotation
35a8b10
@srittau
Revert one more formatting change
a34db42
@srittau
Harden linenos_used_by_groups
bede490
@srittau
Merge branch 'main' into one-success
940418e
@srittau
srittau merged commit 1f8d6f8 into python:main Nov 3, 2026
5 checks passed

Uh oh!

There was an error while loading. Please reload this page.
@srittau
srittau deleted the one-success branch November 3, 2026 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@carljm carljm carljm approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

3 participants

@srittau @davidhalter @carljm
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.