-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add some lint errors to .pylintrc disable list (#2123) #2142
Conversation
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.
Thanks for the PR! I don't think any of these pylint errors make our code better. I'd prefer adding them to the ignore list at https://github.com/benoitc/gunicorn/blob/master/.pylintrc#L13
@berkerpeksag I have added them to |
Except for Especially for For the no else after break, it make the code more compact and avoid big if / else. IMO only |
@Djailla I agree with you. |
I added |
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.
Thank you!
I don't unrstand some changes in the reloader and gthread worker. how are they related? and what do they fix? I mean the else in gthread is here for readability. this ˋif` may be enough but the logic is not explicit. About the ˋcontinue` removal in the reloader module it follows the same logic and is more optimized (it continue the loop now and after evaluating the other sentences) |
@benoitc I can revert the change |
I'm neutral. I like using defaults for linters, rather than doing lots of customization. I also like some of these rules, some of the time. For example, I really like when guards near the top of functions are under def foo():
if guard:
return
# no else because this is not about one thing _or_ the other, just about a precondition It's rare that I find these lint rules to make the code worse, and if it does it can be locally disabled. I'm 👍 for these changes the way they are in this PR right now. |
i'm agree with the general spirit. Although in this two cases, yes, I would prefer to keep it the current way. It's more readable. Rest of the patch is OK, thanks for this. There is a bunch of refactoring that could be done later to modernize the current source but let's not all the warnings dictate all of it for now :) |
|
thanks! |
Fixes #2123