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

Type annotations #35

Open
jack-fs opened this issue Mar 30, 2022 · 1 comment
Open

Type annotations #35

jack-fs opened this issue Mar 30, 2022 · 1 comment
Labels
nicetohave Nice to have enhancement, but not a priority

Comments

@jack-fs
Copy link
Contributor

jack-fs commented Mar 30, 2022

I propose this issue as a place to consolidate high-level typing-related discussion/planning/commits.

The code-base is partially type-annotated; it has been very useful for documentation and testing (in particular when using hypothesis) so far.

Though it would be premature (and a time-sink) at the moment, I imagine that once the code-base settles we could potentially add mypy type-checking to the CI.

@jack-fs jack-fs added the nicetohave Nice to have enhancement, but not a priority label Mar 30, 2022
@jack-fs
Copy link
Contributor Author

jack-fs commented Nov 1, 2022

It may be worth investigating different type checkers, e.g. pytype, which sells itself as focussing on type inference rather than focussing on gradual typing, and is more lenient than mypy.
This combination seems likely to add less unnecessary noise (type annotation noise and type warning noise) to any refactor.

A comparison paper: https://www.cs.rpi.edu/~milanova/docs/dls2020.pdf

Also, for a more PEP-up-to-date, pyright

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
nicetohave Nice to have enhancement, but not a priority
Projects
None yet
Development

No branches or pull requests

1 participant