-
Notifications
You must be signed in to change notification settings - Fork 41
Add tests for type annotations with mypy #1042
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
Conversation
This reverts commit 48ca75b.
Hi @nielsdrost @bouweandela , this PR is ready to be reviewed. Could one of you have a look? |
Sure, I'd be happy to review! Did you try if it works with Python 3.6? Because I would expect the worst support for type annotations there. Up until now, we weren't using any new Python features, but I believe that type annotations are a more recent addition to the language. |
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.
Very nice contribution!
Did you also try the mypy plugin for prospector?
CFG_DEVELOPER = esmvalcore._config.read_config_developer_file() | ||
esmvalcore._config._config.CFG = CFG_DEVELOPER | ||
# Initialize CMOR tables | ||
read_cmor_tables(esmvalcore._config.CFG) | ||
read_cmor_tables(CFG_DEVELOPER) |
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.
This is unsafe code, because it changes a loaded module (esmvalcore._config._config.CFG
) so it can potentially mess up that module. Line 14-17 can be replaced with a safer:
esmvalcore._config.load_config_developer()
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 also don't like that code, but that is how it is at the moment in master
and should be fixed in a separate PR.
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.
You're changing the code in this pull request, so you might as well improve it while you're at it
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'd love to improve it, but that is not the goal of this PR. I only fixed what was necessary to pass the type checks with mypy
👍 If this needs more fixing, then let's do it in a separate issue/PR.
@@ -224,7 +225,7 @@ def test_config_class(): | |||
assert isinstance(cfg['output_dir'], Path) | |||
assert isinstance(cfg['auxiliary_data_dir'], Path) | |||
|
|||
from esmvalcore._config import CFG as CFG_DEV | |||
from esmvalcore._config._config import CFG as CFG_DEV |
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.
Has the location of this import moved in this pull request?
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.
No, as you mentioned in the comment above, this code is unsafe. This test depended on the config developer to be set as esmvalcore._config.CFG
in test_data_finder.py
. The location of _config
was changed in #939.
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.
But why are the tests passing with the old import, if this was changed 2 months ago?
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.
Because test_data_finder
sets the variable:
test_data_finder.py
: esmvalcore._config.CFG = esmvalcore._config.read_config_developer_file()
and then test_config
imports it:
test_config.py
: from esmvalcore._config import CFG as CFG_DEV
When I changed one, I had to change the other. I don't know the reason why it was done this way, but it seemed like I missed this one in #939, so I updated it.
While trying out this pull request, I noticed that sometimes when I run mypy it automatically adds the entry |
I have not tried Python 3.6. Is that part of our test specification? The tests on CircleCI are only with 3.7 afaik. I'm not sure it makes sense to test it with Python3.6, because we will never see the errors. |
I have not. I will add it to Update: seems to work as intended. 😁 |
Yes, ESMValTool and ESMValCore support Python 3.6 and up
They are run with a recent Python version, Python 3.9 at the moment, see e.g. here
It makes sense to test, because if we say we support Python 3.6 and up, we should be sure it works. There is already a nightly GitHub Action run on the master branch that tests all supported Python versions on all supported platforms, see e.g. here. So if there are any errors, we will start seeing them there as soon as this pull request is merged into master. Depending on how easy it is to mess up because type hints are less well supported by older Python versions, it would probably make sense to add a test job that runs on every pull request with the lowest Python version we support. |
If it makes life easier, I think we could drop Python 3.6 support because it's almost end of life anyway. It looks like Python 3.7 and up have better support. |
Either works for me, but if we are supporting 3.6 then I think it would be best if we run our CI tests in the PR on 3.6 to ensure that people do not add unsupported code. |
It would be best to run them with both Python 3.9 (to see that things work the Python version that most people will use and that we're not using too old features that have been removed) and Python 3.6 (to check that we're not using features that are too new and not available yet). Would it be OK with you if I added an extra CircleCI test for Python 3.6 in this pull request? Or would you like to do this yourself? |
I think it is more transparent to add a new CircleCI test for python 3.6 in a separate PR. And then merge that here. EDIT: made an issue here #1055 |
@stefsmeets Could you please fix the issues reported by Codacy and the failing CircleCI tests? |
Done. The other codacy issue was already there, because the function arguments need to match the original one. CircleCI fails are because of the conda_build related to fiona, and a segmentation fault 🤷♂️ |
I think you are referring to the warnings from file esmvalcore/experimental/_warnings.py here, right? What about
and
? These look like things that would need to be solved.
The fiona test problem has been fixed #1046, so you can solve it by merging master into this branch. The segmentation fault can be usually be avoided by clicking the re-run button on CircleCI, see #644. |
Sorry @bouweandela , but I don't see those issues in Codacy. Afaik I already fixed those a long time ago. |
I already re-ran the tests, and now |
The tests pass now, so that should be fine, thanks! |
Description
Hi everyone, this PR adds mypy as an additional test in
pytest
.It also fixes all the type annotations where possible.
Before you get started
Checklist
pre-commit
oryamllint
checksTo help with the number pull requests: