-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Code Quality: Additional lints in this repository (help wanted!) #4776
Comments
Here are some other tools I have glanced at, but not yet fully investigated for usefulness (of the tool itself, or the change):
PRs adding these tools are welcome -- even if you just add it and don't fix any lints (so we can see the magnitude of correction required). We can then discuss the relative merits of these additional tools on that PR. |
This comment tracks the implementation status of new lints:
|
happy to take this one! |
i'll take see #4778 |
Taking the occasion, I'd like to discuss the following, in the hope of be handled as part of this effort:
|
@wagnerluis1982 I have moved that to #4780 |
I'll take this one as well |
Added |
Are any of these plugins redundant? For example, does it make sense to use both |
|
I'll give this one a try. |
Hello @radoering, I played around with it locally and it worked quite well. The only thing I dislike is, that it forces one to put imports from typing, like I would suggest keeping these imports outside the type-checking block and mark them with |
@finswimmer: Easier said than done 😉: snok/flake8-type-checking#49 Fortunately, the maintainer released a new version with my patch as quick as greased lightning. He even made an offer to "add a setting to allow specific module imports - like a whitelist/passlist for modules exempt from checking". For now, I'll add the |
@radoering @finswimmer https://pypi.org/project/future-annotations/ is available as a third option. I'm inclined to just live with strings for now because we can remove them in a month or two when we drop 3.6 support, but if you really want to, there is an option to use the future syntax now. Edit: just saw the linked discussion -- awesome! Looks like we'll get to have our cake and eat it too! |
Here are two more flake8-plugins I find useful: |
That one is actually already implemented! It's pretty useful, yeah. |
Added a new item to the list of 'wanted' lints:
|
I'll have a look at |
I'll gladly pick up the removal of |
I learned about nitpick these days. I wonder if we like to use it, to enforce a minimum set of checks across our repos? |
is this still active? are tools that are not crossed out still to be implemented? |
Hey @Secrus, I would say the tools that are not crossed are debatable, whether we really want to use or not. The only one I really want to see is fin swimmer |
Hey @finswimmer,
I'd like to give this a shot. I saw that |
@dogweather I tried flake8-functions myself, and have few conclusions:
|
I find quite a lot to like in flake8-pie. Not sure I agree with absolutely everything it warns about, but you can always disable the things that you don't want. (I don't plan to work on adding this to the repository, if anyone wants to have a go then we will not be duplicating one another.) |
I would like to add flake8-pie. Can make a PR today or tomorrow. |
Relates-to: #4776 Adding the hook leads to four new warnings for the repo. - [PIE803](https://github.com/sbdchd/flake8-pie#pie803-prefer-logging-interpolation): prefer-logging-interpolation This check produces false positives (`debug()` calls are always flagged as if they belong to a logger). PR ignores such instances and fixes the rest. - [PIE786](https://github.com/sbdchd/flake8-pie#pie786-precise-exception-handlers): precise-exception-handlers PR ignores instances where the intention is indeed to catch any exceptions and fixes the rest. - [PIE798](https://github.com/sbdchd/flake8-pie#pie798-no-unnecessary-class): no-unnecessary-class All instances are ignored via an additional entry in flake8 config.
I'm going to close this for now as the original effort discussed here has largely concluded over the last year. However, please do suggest new linters/code quality tools if you think they may bring improvements to the project's code, or head off common footguns. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
We're doing a bunch of code quality cleanup, and as part of that effort I'd like to implement some additional lints/coding conventions. There will be a lot of manual changes here, so I think these will be some items to have multiple people tackle.
In no particular order:
Addban-relative-imports = true
to.flake8
and remove relative imports from the repo.Addflake8-type-checking==1.0.4
to.pre-commit-config.yaml
withenable-extensions = TC, TC2
in.flake8
, and rework our type annotations for zero runtime cost using string constants. When we drop Python 3.6 support, pyupgrade will be used to automatically switch tofrom __future__ import annotations
and unquote the annotations.Addflake8-use-fstring==1.3
to.pre-commit-config.yaml
and fix all the use of.format()
on string constants in the repo. Start at level 0, and try level 1 if possible. Level 2 is likely useless in this repo (I think we will always use.format()
on string variables), but you could prove me wrong.RemoveE501
from.flake8
-- currently, black leaves our long comments, docstrings, and string constants alone -- let's hand-format them to comply with the line length limit.Please call dibs in this issue to prevent duplicated effort.
(suggestions for additional code quality improvements/tools to enforce them are also welcomed here)
The text was updated successfully, but these errors were encountered: