Fix face_areas type hints and add compute_face_areas return type#1592
Conversation
Signed-off-by: Sai Asish Y <say.apm35@gmail.com>
|
Thank you @SAY-5 for taking the time to look into this and for making this clean pull request! @rajeeja what would be your preferences on how to proceed? I think the fix looks good here when compared to |
|
Thanks for the fix @SAY-5, and nice contribution for a first PR here. This resolves #1590 cleanly. @Sevans711 — let's go ahead and merge this one now; I'll handle the small conflict with #1577 when I merge main in. @SAY-5 out of curiosity, what got you into using uxarray? Always good to hear how people find the project. |
rajeeja
left a comment
There was a problem hiding this comment.
LGTM — clean, correctly scoped fix. Approving.
Closes #1590
Overview
calculate_total_face_area,compute_face_areas, and_compute_face_areasannotatedquadrature_rule,order, andlatitude_adjusted_areawith| None, butNoneis never a valid value and the code does not handle it. Dropped the| Noneso the annotations match the actual accepted types (str,int,bool).tuple[np.ndarray, np.ndarray]tocompute_face_areas(and_compute_face_areas), matching what they return and the existing docstrings.Kept narrowly scoped to the face_areas signatures per @Sevans711's note; the broader codebase-wide sweep is tracked separately.
Expected Usage
PR Checklist
General
Testing
Documentation
_) and have been added todocs/internal_api/index.rstdocs/user_api/index.rstExamples
docs/examples/folderdocs/examples.rsttoctreedocs/gallery.ymlwith appropriate thumbnail photo indocs/_static/thumbnails/