-
Notifications
You must be signed in to change notification settings - Fork 2
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
Introduce types in the whole package #181
Comments
Despite being user-facing, and somehow part of the interface, types are optional in Python. I'll consider them as a non-breaking change, at least for the time being. |
Out of the suggested tools here https://mypy.readthedocs.io/en/stable/existing_code.html#automate-annotation-of-legacy-code only MonkeyType seems a realistic option |
Do not use any automated option: types are useful to add information, while, if the information is already there, you could leave it untyped. This is perfectly fine for Python (to have types only somewhere), since I don't remember what's the default (I could quickly look up), but Mypy for sure has an option to (dis)allow So, let's keep doing it incrementally. If you want to add a bunch of them manually, feel free to do it. But even in that case, please break it in multiple PRs. |
At the moment, type hints has been mainly introduced in
eko.io
, and inconsistently here and there in other places.We should consistently define and use types, as a starting point we should better distribute types that are common to the whole package, lifting a huge part of
eko.io.types
toeko.types
.This will be also helpful for #178
First discussed in #172 (comment)
The text was updated successfully, but these errors were encountered: