search

nipreps / eddymotion

Open-source eddy-current and head-motion correction for dMRI.
https://nipreps.org/eddymotion
Apache License 2.0
15 stars 16 forks source link

Decision on adopting type hints #231

Open jhlegarreta opened 2 months ago

jhlegarreta commented 2 months ago

What would you like changed/added and why?

Some parts of the coder use type hints, whereas others do not. It would be beneficial to make a decision and to keep the code consistent.

Do you have any interest in helping improve the documentation?

Yes

Do you have any suggestions for the new documents?

Adopting type hints is probably good to be able to detect errors earlier.

oesteban commented 1 month ago

I'm :+1: and try to incorporate type annotations when I have the time or need to better interpret the code with the hopes that one day all the code will have type hints.

effigies commented 1 month ago

An unchecked type hint is just a note to your future self, but it also triggers additional checks by the type checker. Adding hints without checking them just makes the task of adopting a type checker more involved.

I would suggest adopting a type checker first, add type checks to your CI (and pre-commit, if it's fast enough), and then begin annotating your project.

jhlegarreta commented 1 month ago

Adding hints without checking them just makes the task of adopting a type checker more involved.

Didn't know that it would make the adoption of a checker more involved.

I would suggest adopting a type checker first, add type checks to your CI (and pre-commit, if it's fast enough), and then begin annotating your project.

Looks a reasonable plan. @effigies please feel free to downvote the adoption of type hints (and checkers) if you do not see any benefit to them; then it is more a decision about consistency in the code.