refactor: add checks for input types in Task

[gcroci2]

• add checks for time vars
• add checks for all remaining input parameters, for all public methods
• fix tests
• add tests for checks
• ignore ANN401 in tests folder

[gcroci2]

• feature: add range functionality to fix_time in Task #68
• refactor: add warning message for max_sequential #65
• refactor: add checks for input types in Task #64 👈
• feature: add range functionality to iti and ntrials parameters of the Task class  #63
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @gcroci2 and the rest of your teammates on Graphite

[DaniBodor]

Wouldn't it be easier to use an external package for enforcing type hints for most of these? Either pydantic or something like this (looks less stable, but was easier to find from documentation how to use do it) can do that.

If we stick to leaving it here, I would suggest to make it a bit more modular as per this comment

[DaniBodor]

I'm not a huge fan of this. I get that it's not pretty to turn it off many times over on individual functions, but I do think it's a good practice to avoid using Any in most cases.

Alternatively, at the top of the test file in question, you can state AnyType = Any #noqa: ANN401, RUF100 as a type alias and then use AnyType wherever you don't want the linter to check without having to noqa each instance.
(the RUF100 ignoring isn't strictly necessary right now, but that is due to a bug in RUF, which I assume will be fixed at some point and then we won't have to fix it post-hoc).

[gcroci2]

In the tests, you do want to test Any types. In the code-base I agree, that wouldn't be good. Very likely, we will need to state the exception at the beginning of each test file, so in my opinion is better to just set it in the toml directly on all tests files. This won't disable the error in the code-base, of course.

[gcroci2]

Wouldn't it be easier to use an external package for enforcing type hints for most of these? Either pydantic or something like this (looks less stable, but was easier to find from documentation how to use do it) can do that.

I'd go for pydantic, since the other one does not seem very reliable, especially for the future. Pydantic seems to have a dataclasses module, that may do the job.

If we stick to leaving it here, I would suggest to make it a bit more modular as per this comment

As commented above, even if I agree that the checks can be definitely modularised more, it is not so trivial and it requires a bit of more careful edits.

What if I open an issue for evaluating pydantic, and if that doesn't work then we open a PR for making what we have now more modular?

[DaniBodor]

Wouldn't it be easier to use an external package for enforcing type hints for most of these? Either pydantic or something like this (looks less stable, but was easier to find from documentation how to use do it) can do that.

I'd go for pydantic, since the other one does not seem very reliable, especially for the future. Pydantic seems to have a dataclasses module, that may do the job.

If we stick to leaving it here, I would suggest to make it a bit more modular as per this comment

As commented above, even if I agree that the checks can be definitely modularised more, it is not so trivial and it requires a bit of more careful edits.

What if I open an issue for evaluating pydantic, and if that doesn't work then we open a PR for making what we have now more modular?

Great idea!

[sonarcloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud