Skip to content
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

Adopt mypy and stronger enforcement of pylint #1719

Open
2 tasks done
Zeitsperre opened this issue Apr 18, 2024 · 0 comments
Open
2 tasks done

Adopt mypy and stronger enforcement of pylint #1719

Zeitsperre opened this issue Apr 18, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request information For development/intsructional purposes standards / conventions Suggestions on ways forward

Comments

@Zeitsperre
Copy link
Collaborator

Addressing a Problem?

Why would we want to do this?

  • Xclim is a scientific library that aims to be strongly typed and optimized; this library is made to do that specifically.
  • Ensuring that variables are always typed and do not change their type during execution is a reliable way of optimizing our code base and evade undefined behaviours.
  • Our code base is already close to compliant with full static typing and type checking that we would get from mypy.

Potential Solution

We start using mypy in our linters and set some fairly high thresholds for pylint. We currently use pylint with some allowances (our code rating is hovering around 9.6/10, so we're nearly there).

mypy is a fairly involved check, so perhaps we would run the comprehensive checks from it as part of the lint job on GitHub, and run a more relaxed threshold for it as part of the pre-commit configurations (to catch obvious errors). pylint can be configured for stronger checks across both (runs very fast).

Although we've already ticked most of the boxes, this change might still need to occur progressively (as the documentation suggests). I can imagine this requiring effort from all maintainers to help determine what can easily be typed and what we can comfortably ignore.

Additional context

I think we have been gradually making our way towards this for several years. The quality of our code has been improved thanks to the existing pylint checks (soft) as well as the battery of linters we use. The last steps needed to ensure mypy-compliant code will help address some finer issues that are often raised in other linters as well (flake8, ruff, vulture)

This goal is something that was also brought up by a few research developers I spoke with at PyCon Lithuania. This would be a medium-effort solution that would provide some security, code optimization, some potential speedups, and would benefit downstream projects hoping to adopt mypy as well for their code bases.

The comprehensive guide to mypy: https://dev.to/tusharsadhwani/the-comprehensive-guide-to-mypy-561m

Contribution

  • I would be willing/able to open a Pull Request to contribute this feature.

Code of Conduct

  • I agree to follow this project's Code of Conduct
@Zeitsperre Zeitsperre added the enhancement New feature or request label Apr 18, 2024
@Zeitsperre Zeitsperre self-assigned this Apr 18, 2024
@Zeitsperre Zeitsperre added standards / conventions Suggestions on ways forward information For development/intsructional purposes labels May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request information For development/intsructional purposes standards / conventions Suggestions on ways forward
Projects
None yet
Development

No branches or pull requests

1 participant