mm21
commented
1 year ago Thanks for bringing this up. Here are some thoughts:
Mypy: I've been planning on adding this, but there are higher priorities for now.
isort: I'd probably support this, with a handful of exceptions for imports which have a certain flow that helps in understanding the design.
pylint: I've always thought projects that use such tools end up much less readable as they're littered with exceptions for various rules. IMO it's best to not waste the reader's attention with such distractions (this is why I like Python, you can have a very high signal to noise ratio). If it reveals genuine bugs in the code I'd be interested in what those are, but I feel it probably won't add much value at this point. In terms of code quality improvement I think we'd be better off working on testing the remaining 5% of the code which isn't covered by tests.
The code is going to be a moving target anyway as some things need to be moved around and refactored to support having a filesystem backing storage in addition to ETAPI. Once the core subpackage is more finalized, maybe some of this can start being done in parallel.
I'll work on writing up these todos and putting them in the upcoming developer documentation.
jwhonce
Is your feature request related to a problem? Please describe. Should project use checkers / linters like pylint and mypy?
Describe the solution you'd like Using these tools make code consistent and may improve quality.
Describe alternatives you've considered I already use vscode's python plugin, isort and black formatter.
Additional context Using these tools can be challenging given python's fluid typing. Pylint is very pedantic about style and typing, a quick run of the current source reports 636 style / code issues. If it Is decided to go this route, pyproject.toml could be configured to allow exceptions to the checks.