-
Notifications
You must be signed in to change notification settings - Fork 74
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
Pylint fixes #159
Pylint fixes #159
Conversation
@LSchueler this is ready for review. |
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.
I just had a very very brief look at this PR. Some changes I could not comprehend so quickly, but most of them look pretty harmless.
Maybe it would be helpful to have one central file (some source code file) where the pylint disabling codes are summarized or has the documentaion gotten better over time? - The last time I was setting the linter, it was a real pain to find the correct codes.
Actually, I think I would prefer a description on why each setting was made for each file. I'm just not sure how cluttered the files would be.
But anyway, I'm really curious to see what the Linter will complain about in my future code :-)
@LSchueler there is this Project: https://vald-phoenix.github.io/pylint-errors/ where the error-codes are documented quite well. I added a section in |
That's great, I like the summary and also that you can find it in |
…s not allowed here
... I've done it. Pylint is a pain, but a good one.
I created a setup for Pylint in
pyproject.toml
that should warn us about bad practice. I added a new stage in CI to check pylint.Certain Pylint rules are disabled per file, where it makes sence (at least for me).
It helped me figure out all of the circular imports (see #24). Especially the matplotlib imports are now in a try block and later on deferred.
All remaining pylint warnings were sorted out here.