-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Saner linters #58
Saner linters #58
Conversation
@@ -35,11 +35,8 @@ jobs: | |||
pixi-version: v0.39.0 | |||
cache: true | |||
environments: lint | |||
- name: Run Pylint, Mypy & Pyright | |||
run: | | |||
pixi run -e lint pylint |
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.
Redundant and incompatible with ruff
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.
Pylint is also included in ruff, so why would it be incompatible?
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.
there are many pylint rules that ruff hasn't implemented: astral-sh/ruff#970
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.
A simple example was
class at:
pylint complains that classes need to be capitalized;
but if you add a # noqa
to silence pylint, then ruff fails with an "unnecessary noqa" error
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.
the way to silence pylint is # pylint: disable=invalid-name
run: | | ||
pixi run -e lint pylint | ||
pixi run -e lint mypy | ||
pixi run -e lint pyright |
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.
Can't have pyright AND mypy in the same project. They will eventually result conflicting with each other, and in fact they did so heavily in #53.
Chose mypy as I found pyright extremely obnoxious and factually wrong in too many cases.
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.
Can't have pyright AND mypy in the same project. They will eventually result conflicting with each other, and in fact they did so heavily in #53.
This isn't true at all, and all of my typed projects are proof of this.
In my experience, there are indeed situations where mypy and pyright behave differently. In at least 99% of these cases, this is caused by one of the >1200 confirmed bugs in mypy that aren't present in pyright: https://github.com/erictraut/mypy_issues
Chose mypy as I found pyright extremely obnoxious and factually wrong in too many cases.
Do you have an example of this?
@@ -70,9 +70,7 @@ array-api-extra = { path = ".", editable = true } | |||
|
|||
[tool.pixi.feature.lint.dependencies] | |||
pre-commit = "*" | |||
pylint = "*" | |||
basedmypy = "*" |
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.
replaced basedmypy with mypy. I think it is an extremely bad idea to diverge from PEPs. Namely, IDE plugins will not support this.
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 is untrue. All mypy IDE plugins and other CI tools also work with basedmypy
.
In fact, mypy diverges more from the typing specification that basedmypy
does. It also has significantly more bugs.
Overall I'm -1 on this change. I'm happy to investigate conflicts.
That isn't true, it is done successfully in @jorenham's scipy-stubs. |
Quick comment: conceptually this PR seems right. Best to pick 1 linter and 1 type checker, everything else is pretty much unworkable once the code starts getting more complex. I'd personally pick |
Let me take a look at resolving the issues @crusaderky is facing. If it really is unworkable, then of course, we should make changes to make it workable. |
In case of linters I'd agree with this, unless they're actually linting different things. In my project I always use (only) ruff for python, but I also always markdownlint, and in most cases also repo-review. These are all disjoint, so I see no problem with that. I don't agree that you should only should pick one type checker. I always use both mypy and pyright in my projects, because I want the users to also be able to use both, which requires me to verify that both type-checkers actually understand the typing annotations. |
RE: pylint, the Scientific Python Development guide says
We currently use the recommended limits on the default checks. If there are conflicts with ruff then it shouldn't be difficult to extend that list. |
typeshed uses both mypy and pyright |
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.
it looks like this is workable without changing the existing config - see gh-59
Thorough review of the linters in use. This was triggered by #53, where I found many unresolvable conflicts among the linters.