MAINT: testing: rename parameters x/y to actual/desired#24978
MAINT: testing: rename parameters x/y to actual/desired#24978ngoldbaum merged 2 commits intonumpy:mainfrom
Conversation
| return decorator | ||
|
|
||
|
|
||
| def _rename_parameter(old_names, new_names, dep_version=None): |
There was a problem hiding this comment.
Adapted from https://github.com/scipy/scipy/blob/2c6f5c67d5870e3058c8b7b7818bcb8a940bfeee/scipy/_lib/_util.py#L730
All I did was change "SciPy" to "NumPy" and add the loop.
I can bring in more extensive tests of the decorator (https://github.com/scipy/scipy/blob/5dc8a79e482118d150d9430598f52d17251317f1/scipy/_lib/tests/test__util.py#L221) if desired.
| dep_version : str, optional | ||
| Version of NumPy in which old parameter was deprecated in the format | ||
| 'X.Y.Z'. If supplied, the deprecation message will indicate that | ||
| support for the old parameter will be removed in version 'X.Y+2.Z' |
There was a problem hiding this comment.
Deprecations in NumPy are for two minor versions (like SciPy), or is the schedule different?
There was a problem hiding this comment.
@rgommers do you think I should email the mailing list about this change or wait for a better time?
There was a problem hiding this comment.
Probably first get the review completed I'd say, since the end result may still change. It's a pretty minor deprecation, since I'd expect usage of the keyword form to be rare.
| def test_xy_rename(assert_func): | ||
| # Test that keywords `x` and `y` have been renamed to `actual` and | ||
| # `desired`, respectively. These tests and use of `_rename_parameter` | ||
| # decorator can be removed before the release of NumPy 2.2.0. |
There was a problem hiding this comment.
Would you like the test to raise in NumPy 2.2 as a reminder?
| with pytest.warns(DeprecationWarning, match=dep_message), \ | ||
| pytest.raises(TypeError, match=type_message): | ||
| assert_func(1, x=1) | ||
| assert_func(1, 2, y=2) |
There was a problem hiding this comment.
Let me know if you'd like to see other cases. I didn't think an exhaustive test was necessary.
|
@seberg @ngoldbaum thought I should bring this to your attention since we discussed it in gh-24931. Thanks for considering it! |
|
I think renaming as is done here is fine. Making them positional-only would be fine too, but |
|
Thanks @ngoldbaum. Let me know if you think the PR is ready for an email to the mailing list. |
|
Maybe give it until next week for people to look at this? Making the CI pass by fixing the linter issue might help. |
[skip cirrus] [skip circle] [skip azp]
|
I commented that I'd hold off on re-running CI for other comments, but ok, I went ahead and committed the fix. |
|
I thought we had the CI set up so if the linter fails it cancels the other jobs. I appreciate the sensitivity to not wasting cloud CI resources! I only mentioned fixing the CI because in my experience people tend to skip over PRs with a red x next to them 🙃 |
No, because sometimes trying to make the linter parse is weird. Although I guess you could do it with some ignores, etc. |
| `numpy.testing.assert_array_equal` and | ||
| `numpy.testing.assert_array_almost_equal` | ||
| has been deprecated. Pass the first two arguments as positional arguments, | ||
| instead. |
There was a problem hiding this comment.
This probably doesn't render well, either make it a bullet point with an initial * and indentation, or give it a title with ----.
|
We chatted about this in the triage meeting and we agreed we'd like to merge this as-is. Thanks @mdhaber! |
…_array_almost_equal()` positional only xref numpy#24978
…_array_almost_equal()` positional only xref numpy#24978
As discussed in gh-24931, this renames parameters
xandyofnumpy.testing.assert_array_equalandnumpy.testing.assert_array_almost_equaltoactualanddesiredbecause these names are more descriptive and consistent with the other assertion functions. Backward compatibility is maintained by allowing the use ofxandyas keyword arguments with a deprecation warning.One additional comment in gh-24931 was that these arguments could be positional-only. I don't use these as keywords, but personally I don't think it would be a bad idea, since it is not uncommon to mix them up, and
actualanddesiredare concise yet descriptive names. We just fixed a load of such cases in SciPy, for example. If positional-only is the consensus of NumPy maintainers, I would need to reconsider this PR since the existing decorator wouldn't work as written and presumably all assert functions would need to be changed for consistency.Presumably I should check with the mailing list about the deprecation?