-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
MAINT: testing: rename parameters x/y to actual/desired #24978
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -27,3 +29,59 @@ def decorator(func): | |||
func.__module__ = module | |||
return func | |||
return decorator | |||
|
|||
|
|||
def _rename_parameter(old_names, new_names, dep_version=None): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deprecations in NumPy are for two minor versions (like SciPy), or is the schedule different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the same indeed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
x
andy
ofnumpy.testing.assert_array_equal
andnumpy.testing.assert_array_almost_equal
toactual
anddesired
because these names are more descriptive and consistent with the other assertion functions. Backward compatibility is maintained by allowing the use ofx
andy
as 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
actual
anddesired
are 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?