Update type checking to use numpy NDArray and ArrayLike#133
Conversation
…numpy typing suggested practices. Co-authored-by: Liam Pattinson <liampattinson@gmail.com>
662e361 to
39d7650
Compare
323db26 to
fc8fbab
Compare
There was a problem hiding this comment.
Pull Request Overview
This PR updates the type checking for handicap functions by replacing the custom FloatArray type with standard numpy typings (ArrayLike and NDArray), and adjusts error messages to reflect these changes.
- Replace and simplify type hints across several modules
- Update error messages for type conversions
- Remove the deprecated FloatArray type from the codebase
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| archeryutils/handicaps/tests/test_handicap_tables.py | Updated expected error message for invalid handicap inputs |
| archeryutils/handicaps/handicap_tables.py | Adjusted type hints (using npt.ArrayLike and NDArray[np.float64]) and streamlined input sanitization |
| archeryutils/handicaps/handicap_scheme_agb.py | Updated type annotations to use npt.ArrayLike and NDArray[np.float64] |
| archeryutils/handicaps/handicap_scheme_aa.py | Updated type annotations to use npt.ArrayLike and NDArray[np.float64] |
| archeryutils/handicaps/handicap_scheme.py | Removed FloatArray alias and overload signatures; unified type hints with npt.ArrayLike |
| archeryutils/handicaps/handicap_functions.py | Updated type hints to align with the revised numpy typing scheme |
| archeryutils/handicaps/init.py | Removed FloatArray from the exported symbols |
| archeryutils/classifications/agb_old_indoor_classifications.py | Converted hard-coded handicap lists to numpy arrays with explicit float64 type |
There was a problem hiding this comment.
Pull Request Overview
This PR updates the type annotations across the codebase to use numpy’s official typing constructs (npt.ArrayLike and npt.NDArray[np.float64]) in place of the custom FloatArray type. It also removes the FloatArray alias and updates function signatures, docstrings, and error messages accordingly.
- Updated type hints in handicap schemes, tables, and functions
- Removed the custom FloatArray alias for a more standardized approach
- Revised error messages and documentation to reflect the changes
Reviewed Changes
Copilot reviewed 8 out of 9 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| archeryutils/handicaps/tests/test_handicap_tables.py | Updated error message match string in tests to reflect new type-checking behavior |
| archeryutils/handicaps/handicap_tables.py | Changed type annotations and output types for handicap tables and input sanitization |
| archeryutils/handicaps/handicap_scheme_agb.py | Updated sigma_t function signature and added explicit numpy array conversion |
| archeryutils/handicaps/handicap_scheme_aa.py | Updated sigma_t function signature and added explicit numpy array conversion |
| archeryutils/handicaps/handicap_scheme.py | Removed custom FloatArray and updated all function signatures and return types |
| archeryutils/handicaps/handicap_functions.py | Updated type annotations in helper functions to align with new numpy type hints |
| archeryutils/handicaps/init.py | Removed FloatArray export to enforce standard types |
| archeryutils/classifications/agb_old_indoor_classifications.py | Converted classification handicap lists to np.array for consistency |
Files not reviewed (1)
- docs/develop/whats-new.rst: Language not supported
|
How far should
if not numpy.can_cast(np.asarray(input), np.float64):
Raise("Inappropriate input for code. Must be numeric value.")Perhaps wrap this up as a reuseable function, and even use it to return the input cast to a |
np.float64. Also catches a couple of documentation typos.
|
Decided to allow it to propagate all the way to the bottom ( Only downside is that anyone who implements a new scheme should build this into their implementation of |
LiamPattinson
left a comment
There was a problem hiding this comment.
I think this all looks better now. Just have a few comments.
How far should
ArrayLikebe allowed to propagate in the code?
I think the way you've done it is sensible. The rules I generally follow are:
- If you call any NumPy functions on some input, type it as
ArrayLikeand usenp.asarray(x)at the top of the function. - If you only pass
ArrayLikethings to other functions takingArrayLike, simply propagate it forward. - If something must be a NumPy array on entry, instead type it as
npt.NDArray[np.float64](or something similar).
than using typing.cast Co-authored-by: Liam Pattinson <liampattinson@gmail.com>
LiamPattinson
left a comment
There was a problem hiding this comment.
Cool, looks good to me 👍
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #133 +/- ##
==========================================
+ Coverage 97.92% 97.94% +0.01%
==========================================
Files 31 31
Lines 2028 2043 +15
==========================================
+ Hits 1986 2001 +15
Misses 42 42
🚀 New features to boost your workflow:
|
Use numpy typing closer to intended use as suggested by @LiamPattinson in #130
Take inputs to functions as
ArrayLike, casting usingnp.asarray()where appropriate.Return items as
NDArray[float64]with single values being duck-typed in the majority of cases.Removes the
FloatArraytype to just useNDArray[float64]explicitly.Resolves a number of issues seen in latest mypy in a more sensible manner than #130
Also allows us to simplify some of the "type-checker" appeasement throughout the code e.g. castings and overloads.