Hi all, In gh-31848 <https://github.com/numpy/numpy/pull/31848>, numpy.unwrap has been reimplemented as a generalized ufunc, targeting the 2.6.0 release. Below is a summary of what's changing. The core of unwrap is now a generalized ufunc written in C++. That is a new private ufunc _unwrap with signature (n),(),()->(n), covering the floating point and signed integer dtypes, computed in a single pass without the intermediate arrays the previous python implementation had to allocate. We've seen that this offers a 2x-3x speedup and lower memory usage. As a result, unwrap now preserves ndarray subclasses instead of always returning a base ndarray. The one exception is masked arrays. A mask-aware unwrap is genuinely ill-defined for this algorithm, so masked arrays (and their subclasses) get unmasked and the operation runs on a plain ndarray instead, same as before. I will open a separate issue and have put a TODO in the codebase to perhaps get a proper mask-aware unwrap in the np.ma module. Two edge-case behavior changes: - An explicitly typed discont argument wider than the result dtype used to get promoted. It's now compared at the result dtype instead. This can change the result by up to ~1 ULP in that specific case. - Calling unwrap with an unsigned integer period that can't represent the values needed internally used to raise OverflowError (from an internal mod call). it now raises TypeError (a "no loop found" ufunc error reporting the mismatched dtypes) instead. If you maintain an array library that implements __array_ufunc__ and tries to stay compatible with all of numpy, you'll now see a call to _unwrap where unwrap previously dispatched through a sequence of familiar public ufuncs (subtract, remainder, cumsum, etc.). If your override doesn't recognize _unwrap but still handles those underlying ops, unwrap falls back to a pure Python path built from them, so things should keep working. If it declines everything unconditionally, unwrap will now raise instead of silently doing the wrong thing. Astropy is the library we know of that might care here, flagging in case others maintain something similar. Kind regards, Iason.