I bisected NumPy against the SciPy maintenance/1.16.x branch and found some newly-occurring test failures are the result of the commit below the fold.
Details
4e00e4df15528323f6d76bbd40157b582861af86 is the first bad commit
commit 4e00e4df15528323f6d76bbd40157b582861af86
Author: kibitzing <[email protected]>
Date: Sat Aug 16 21:20:52 2025 +0900
ENH: Add ndmax parameter to np.array to control recursion depth (#29569)
* ENH: add ndmax parameter to np.array
* ENH: validate ndmax argument is positive
* TST: add ndmax tests for array creation
* ENH: allow np.array with ndmax=0 to create 0-D array
* MNT: simplify ndmax validation and error message
* MNT: improve consistency in error message formatting
* DOC: add comment explaining legacy behavior of max_depth=0
* TST: update tests to reflect new ndmax validation and error message
* DOC: add documentation and examples for np.array ndmax parameter
* DOC: add release note for numpy.array ndmax parameter
doc/release/upcoming_changes/29569.new_feature.rst | 27 ++++++++
numpy/_core/_add_newdocs.py | 26 +++++++-
numpy/_core/src/multiarray/array_converter.c | 2 +-
numpy/_core/src/multiarray/ctors.c | 19 +++++-
numpy/_core/src/multiarray/multiarraymodule.c | 28 ++++++---
numpy/_core/src/multiarray/scalartypes.c.src | 2 +-
numpy/_core/tests/test_multiarray.py | 73 ++++++++++++++++++++++
7 files changed, 162 insertions(+), 15 deletions(-)
create mode 100644 doc/release/upcoming_changes/29569.new_feature.rst
That's from gh-29569, which touches C code, and SciPy also has some tricky NumPy C API business going on in the test failures at scipy/scipy#23543. Could we get a solution that is backwards compatible, even if the conclusion is that SciPy is misbehaving here?
I'll try to dissect a bit deeper in _lfilter.cc maybe--it may be that we're using an argument incorrectly, but even so, if fully backwards compatible down to bare metal it shouldn't break.
I bisected NumPy against the SciPy
maintenance/1.16.xbranch and found some newly-occurring test failures are the result of the commit below the fold.Details
That's from gh-29569, which touches C code, and SciPy also has some tricky NumPy C API business going on in the test failures at scipy/scipy#23543. Could we get a solution that is backwards compatible, even if the conclusion is that SciPy is misbehaving here?
I'll try to dissect a bit deeper in
_lfilter.ccmaybe--it may be that we're using an argument incorrectly, but even so, if fully backwards compatible down to bare metal it shouldn't break.