Open
Conversation
veegalinova
force-pushed
the
vg/feat/based-pyright-switch
branch
from
6facd76 to
92bfdde
Compare
jdeschamps
requested review from
a team,
jdeschamps and
melisande-c
and removed request for
melisande-c
Member
|
I like it! I have been getting annoyed with mypy recently on some stuff to do with It seems though, when run as a pre-commit on github the .env no longer exists, there might be a way to create the env first or we could skip the hook on the CI and instead have a different CI job for |
melisande-c
reviewed
Feb 18, 2026
| "src/careamics/losses/lvae/losses.py", | ||
| "**/*.ipynb" | ||
| ], | ||
| "pythonVersion": "3.12", |
Member
There was a problem hiding this comment.
Also we currently support from 3.11 so we should probably use that python version
jdeschamps
added a commit
that referenced
this pull request
Mar 27, 2026
## Description Following #827, this PR enables pre-commit hooks for `CAREamistV2` and attempts to solve the errors. Note that there is something fishy with the use of `TypeVar` that `mypy` disagrees with: ```python src/careamics/careamist_v2.py:128: error: Argument 1 to "_load_model" of "CAREamistV2" has incompatible type "NGConfiguration[CAREAlgorithm] | Path | None"; expected "NGConfiguration[AlgorithmConfig] | Path | None" [arg-type] src/careamics/careamist_v2.py:128: error: Argument 1 to "_load_model" of "CAREamistV2" has incompatible type "NGConfiguration[N2NAlgorithm] | Path | None"; expected "NGConfiguration[AlgorithmConfig] | Path | None" [arg-type] src/careamics/careamist_v2.py:128: error: Argument 1 to "_load_model" of "CAREamistV2" has incompatible type "NGConfiguration[N2VAlgorithm] | Path | None"; expected "NGConfiguration[AlgorithmConfig] | Path | None" [arg-type] Found 3 errors in 1 file (checked 1 source file) ``` One way to solve it to redefine `AlgorithmConfig` in the same module, rather than importing it. It seems that allows "bounding" the type to the functions it is used in. But it would be annoying to have to redefine the generics in every module. I decided to just ignore it for now for two reasons: - #817 introduces a validator that may improve the situation - Maybe pyright (#698) will be better suited
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
3 participants
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
Note
tldr: Switch from mypy to basedpyright for better type checking
Background - why do we need this PR?
When working on a new feature, I got some super annoying mypy false positive errors that were not informative and did not actually protect the code from any real issues.
Currently, many people have migrated to
pyrightinstead. In general, it has more coverage and strictness thanmypy, should be faster, and (in my opinion) captures more important stuff than mypy does - more on differences here.Overview - what changed?
I replaced
mypywithbasedpyright. Whybasedpyrightand not the regural one?basedpyrightis a community fork of pyright that implements some neat features useful to us.The main one is
baselinethat helps with gradual migration. Instead of getting hundreds of new type errors, we fix the current state of code as "acceptable". Only new code must pass strict type checks. All unresolved stuff is stored in.basedpyright/baseline.json, which we can resolve gradually.Other improvements in basedpyright vs standard pyright here.
Implementation - how did you implement the changes?
basedpyrightto dev dependenciespyrightconfig.jsonwith strictness settingsChanges Made
New features or files
.basedpyright/baseline.json- snapshot of current unresolved errorspyrightconfig.json- type checking configuration.pre-commit-config.yaml- replaced mypy hook with basedpyright hookModified features or files
pyproject.toml- addedbasedpyrightto dev dependenciesRemoved features or files
pyproject.tomlsectionBreaking changes
None for users.
For developers:
pre-commit installto update local hooksbasedpyrightextension and disable the default pylance/pyright extensionAdditional Notes and Examples
Please ensure your PR meets the following requirements: