-
Notifications
You must be signed in to change notification settings - Fork 17
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
using type hint/type annotation by default #5
Comments
I vote for "yes at some point". Definitely a good practice, but I think that in this this project we will be contributing our previously-written code in a first time, so enforcing type-checking early could be a slow-down. |
The good thing is that you can have 'mixed code', part annotated, part unannotated. The IDE won't complain about this state. The pre-commit checkers can have a whitelist for the unannotated part. The unannotated part later on can be:
|
Maybe do this on a voluntary basis initially and update / enforce later if we see fit? |
Sure, sounds good to me! |
Type hinting has been revamped in python 3.5 (I think), and offers a consistent notation for type hinting in the source code:
http://veekaybee.github.io/2019/07/08/python-type-hints/
Most IDEs now support this, and checks the type hints during coding, also packages can do type checking before commiting to the repo. I highly recommend it!
Any questions, comments?
The text was updated successfully, but these errors were encountered: