[sanjaygrr]

Closes #304.

As discussed there, masked_array_support now passes out=None explicitly along with where=, so numpy 2.5 no longer warns about uninitialized memory. Values under the mask stay uninitialized, as before.

Multi-output ufuncs reject a bare out=None (TypeError: 'out' must be a tuple of arrays), so those get one None per output. The count comes from the types attribute the wrappers already expose, e.g. 'dd->dd'. An out passed by the caller still takes precedence.

Checked on Python 3.14.7 with numpy 2.5.4:

• pytest gsw/tests -W error::UserWarning: 670 passed (test_p_from_z_ok[zp4] used to emit the warning);
• masked inputs to p_from_z, SA_from_SP and the two-output CT_first_derivatives return correctly masked results with no warning;
• a user-supplied out= array still works.

[DocOtak]

@sanjaygrr Looks like you beat me to it haha, and did it better!

@efiring there is a lot of ufunc machinery that is hidden by all the wrapping going on. Properties like nout, nin and functions like at, accumulate, reduce etc... it would be nice to get this exposed somehow, it would especially help with this wrapper to have the underlying nout be exposed.

[efiring]

I can easily add the nin and nout attributes, but I don't see any point in adding any of the methods. Is there any real use case for any of them? Do any of them even make sense in this context?

[DocOtak]

Those methods probably aren't useful, my suggestion was more from an expectation that the functions in the library are ufuncs and get surprised when the interface doesn't match. Things like function signatures, e.g. the wrapped ufuncs didn't support kwargs at all until #98, or properties e.g. I had some expectation that nin and nout properties existed.

Adding just nin and nout properties are good enough for this issue/PR, but maybe consider matching the full ufunc interface, or doing a functools.wraps style __wrapped__ for direct access to the underlying ufunc.