JOSS does not directly require some level of code quality - hence the following is independent of the review. Also code quality is often quite subjective. Nevertheless, the higher quality your codebase is, the easier it is to onboard new developers and the less likely they will develop their own tool because yours misses one feature.
Consider renaming WeatherQC._obtain_data to avoid confusing with the input_files._obtain_data function
The input_files._obtain_data function is almost 300 lines long. Consider breaking it into smaller parts which also forces you to structure the logic of your code
Remove the underscores from all the functions in input_files.py because they are used by other modules
Use a code formatter like Yapf of Black to format your code - removes visual clutter without you having to do it manually. VS Code has a "format on save" setting.
Consider return less tuples (like in calc_functions.calc_temperature_variables) and relying more in dicts where each item is a names value - i.e. return_value["monthly_k_not"] instead of return_value[3]. When possible, you might split up the functions so that each function calculates one thing.
The same is true for long lists of input variables (like in calc_functions.calc_humidity_variables). These make it so easy to accidentily pass tmin, tavg, tmax, ... instead of tmax, tmin, tavg.
I can give you a full review regarding code quality - if you want. But I also don't want to spam you with optional/stylistic comments ^^ Tools for automated code reviews can be very helpful too.
In general, I am a big fan of static typing for production codebases. With static type hints you can use Mypy to test your code on typing errors. However, I understand that it adds complexity to a codebase for developers who have not used it before. There are pro's and con's to it but I found it to save a lot of time because many bugs are caught by MyPy in (CI) tests instead of at runtime.
You can add Yapf/Black/Mypy options to a pyproject.toml file.
This issue is related to the review process for JOSS: https://github.com/openjournals/joss-reviews/issues/6368
JOSS does not directly require some level of code quality - hence the following is independent of the review. Also code quality is often quite subjective. Nevertheless, the higher quality your codebase is, the easier it is to onboard new developers and the less likely they will develop their own tool because yours misses one feature.
WeatherQC._obtain_datato avoid confusing with theinput_files._obtain_datafunctioninput_files._obtain_datafunction is almost 300 lines long. Consider breaking it into smaller parts which also forces you to structure the logic of your codeinput_files.pybecause they are used by other modulescalc_functions.calc_temperature_variables) and relying more in dicts where each item is a names value - i.e.return_value["monthly_k_not"]instead ofreturn_value[3]. When possible, you might split up the functions so that each function calculates one thing.calc_functions.calc_humidity_variables). These make it so easy to accidentily passtmin, tavg, tmax, ...instead oftmax, tmin, tavg.I can give you a full review regarding code quality - if you want. But I also don't want to spam you with optional/stylistic comments ^^ Tools for automated code reviews can be very helpful too.
In general, I am a big fan of static typing for production codebases. With static type hints you can use Mypy to test your code on typing errors. However, I understand that it adds complexity to a codebase for developers who have not used it before. There are pro's and con's to it but I found it to save a lot of time because many bugs are caught by MyPy in (CI) tests instead of at runtime.
You can add Yapf/Black/Mypy options to a
pyproject.tomlfile.