Closed ev-br closed 2 months ago
I'd like to give it a go. Any hints? Should I create a new test file?
Maybe this strict iterable verification will create many errors in the libraries that depend on this
Would be great @luxedo !
The logic which does not tell a tuple of arrays from a list of arrays is here: https://github.com/scipy/scipy_doctest/blob/main/scipy_doctest/impl.py#L329
Test cases could be added to tests/module_tests.py, see https://github.com/scipy/scipy_doctest/pull/157 for an example.
EDIT: the check can be hidden behind a new variable in DTConfig if it turns out to be too strict/noisy.
I feel that this is a little more complicated. How strict should the library be with iterables? I got some errors like the following testing SciPy's doctests:
343
344 Finally, the problem states that both decision variables must be integers:
345
346 >>> integrality = np.ones_like(c)
347
348 We solve the problem like:
349
350 >>> from scipy.optimize import milp
351 >>> res = milp(c=c, constraints=constraints, integrality=integrality)
352 >>> res.x
Expected:
[2.0, 2.0]
Got:
array([2., 2.])
This always worked and should keep working, I'd say.
Okay, so this check must be made exclusively when both Expected
and Got
are tuples and lists.
I added more tests and SciPy's tests now pass
Case in point: np.gradient, which changed from returning a list of arrays to a tuple of arrays in numpy 2.0, cf https://github.com/numpy/numpy/pull/26538