Conversation
Member
Author
|
This introduced new Mypy errors: The first 2 aren't necessary (Pyright infers that For now, I'll plan to add |
huddlej
reviewed
Oct 27, 2025
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1922 +/- ##
==========================================
+ Coverage 74.44% 74.46% +0.02%
==========================================
Files 82 82
Lines 9089 9098 +9
Branches 1853 1853
==========================================
+ Hits 6766 6775 +9
Misses 2020 2020
Partials 303 303 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
4 tasks
From doc¹:
Generate or suppress diagnostics for general type inconsistencies,
unsupported operations, argument/parameter mismatches, etc. This covers
all of the basic type-checking rules not covered by other rules. It does
not include syntax errors.
Existing issues will be addressed in subsequent commits.
¹ https://microsoft.github.io/pyright/#/configuration?id=type-check-rule-overrides
Raising a string literal instead of a proper exception is not allowed by Pyright.
This allows Pyright to know the dict structure for type checking.
This removes duplicated lambdas and the need for type annotation on the 'seen' variable.
5a213dc to
135fd7b
Compare
There was a type error with the previous code:
subsample.py:353:12 - error: Invalid conditional operand of type "Series[bool]"
Method __bool__ for type "Series[bool]" returns type "NoReturn" rather than "bool" (reportGeneralTypeIssues)
This is because iterrows() yields Series, and Series.__getitem__ returns
Series[Any] | Any (scalar). Pyright sees row[…] as that type, which
means the outcome of the comparison operator is Series[bool] | bool.
Series[bool] cannot be used as-is for the if condition.
This could be addressed by casting 'int(…) < int(…)', but switching to a
loop targeted on specific columns with itertuples() seems more
appropriate as it addresses the type error and is more efficient.¹
¹ https://stackoverflow.com/a/70227993
Errors for augur/validate_export.py:
Need type annotation for "seen" [var-annotated]
This is unnecessary – Pyright correctly infers that seen is ~TreeAttrs.
135fd7b to
57c36c4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description of proposed changes
Enable
reportGeneralTypeIssuesand address existing issues. Commits roughly ordered from simplest to most complex.Related issue(s)
Follow-up to:
augur/pyrightconfig.json
Lines 14 to 15 in e19f2c2
#1917 (review) suggested adding type hints, and I figured this PR would make the hints more useful.
Checklist