We were perhaps overly permissive in the return type, I'm pretty sure we always return Masked Array, so may as well say so, so that downstream can rely on that (which they already are, to be clear...)

PR checklist

"closes #0000" is in the body of the PR description tolink the related issue
new and changed code istested
Plotting related features are demonstrated in anexample
New Features andAPI Changes are noted with adirective and release note
Documentation complies withgeneral anddocstring guidelines

Adjust type hint of Norm.__call__ to return masked array

47d155d

xrefpydata/xarray#8030We were perhaps overly permissive in the return type, I'm pretty sure we always return Masked Array, so may as well say so, so that downstream can rely on that (which they already are, to be clear...)

Copy link

Member

QuLogic commentedAug 2, 2023

You can also pass a scalar in and get a scalar out; should weoverload that?

Copy link

MemberAuthor

ksunden commentedAug 2, 2023

Hmmmm... right you are... that ... complicates things as "scalar" is not a very easy thing to type hint even those from "ArrayLike" are actually insufficient... (and we do want to accept the non-scalar array likes (not just arrays...)

perhaps

@overloaddef__call__(self,value:np.ndarray,clip:bool|None= ...)->np.ma.MaskedArray: ...@overloaddef__call__(self,value:ArrayLike,clip:bool|None= ...)->ArrayLike: ...

It's a little funky because the signatures are overlapping (whichcan be a problem to mypy... at least xarray is having a problem along those lines, but I think we may be saved by the return types being compatible, just one is more restricted...)

This seems to help with xarray without causing us problems.

Lists and other non-ndarray array likes (including scalars, to the extent that scalars are supported by type hints at all) will just not get the type narrowing that the output is a masked array, but those that care can easily donp.asarray or similar to get that type specifically.