-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
WIP: more annotations #3090
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
WIP: more annotations #3090
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3090 +/- ##
=========================================
+ Coverage 92.16% 92.6% +0.44%
=========================================
Files 63 63
Lines 12787 12799 +12
Branches 2906 2907 +1
=========================================
+ Hits 11785 11853 +68
+ Misses 688 630 -58
- Partials 314 316 +2 |
self, | ||
chunks: Union[ | ||
None, | ||
Number, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last I checked, type checkers were much happier with int
rather than numbers.Number
. Maybe mypy has been updated since then, though....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dask will happily accept float, numpy.int64, etc. and transparently cast them to int.
Should we decide that dask is excessively nice and the intended input must strictly be int?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vote to lean towards wider input bounds - it much more annoying for users to have false negatives than false positives; so in this case Number
assuming mypy understands that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, let's give this a try. We can always change later, that's not a big deal.
One other minor note -- it would be great to define a few type aliases for these longer types. The line wrapping you've done here helps, but this is still very long to write in a function signature.
Thanks @crusaderky. This is great, please keep them coming! By the way, codecov updates its coverage reports as the tests on Azure complete. So usually in the first comment you'll see absurdly low coverage, but if you wait another ten minutes it will edit with the complete results. I don't know how to fix this easily, but fortunately it's only a minor annoyance. |
@shoyer On the first run the pytests themselves (not codecov) were showing half of the tests as "skipped". As if all optional dependencies randomly and silently failed to install. Not sure why. As a direct result codecov was showing a drop in coverage. |
No description provided.