-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
ENH: show warning when np.maximum receives more than 2 inputs #29052
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
base: main
Are you sure you want to change the base?
Conversation
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.
I wouldn't mind discussing whether we should start forcing out=
more generally, since the overhead of using out=
is pretty low now.
But maybe we say maximum is special, which is fine:
- You are doing twice the same thing in the same code.
- Do not just go to an error, this should go through a
DeprecationWarning
. Maybe one can argue that it is almost always a bug and we go directly to aVisibleDeprecationWarning
. But I am a bit skeptical, also becauseDeprecationWarnings
are seen more these days anyway.
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.
I don't think this should happen just for maximum
(though that discussion is perhaps best done in #27639).
But it certainly shouldn't be in the hot path for every ufunc -- instead, on l.4321 (original one), one could do
if NPY_UNLIKELY(len_args != nin) {
if (len_args <= nop) {
/* new deprecation stuff */
}
else {
PyErrFormat(...);
goto fail;
}
}
275aba6
to
e4d6fa4
Compare
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.
Thanks, but this needs some work, also you didn't address the discussion around minimum and maximum.
@@ -4325,7 +4343,28 @@ ufunc_generic_fastcall(PyUFuncObject *ufunc, | |||
ufunc_get_name_cstr(ufunc) , nin, nop, len_args); | |||
goto fail; | |||
} | |||
/* Extra positional args but *no* keywords? */ | |||
if (len_args > nin && (kwnames == NULL || PyTuple_GET_SIZE(kwnames) == 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.
Maybe marten suggested it, but no, this isn't the right place, please look around a bit (further down).
|
||
/* legal out? -> skip */ | ||
if (PyArray_Check(extra) || extra == Py_None || | ||
_is_sequence_of_arrays_or_None(extra)) { |
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.
What is this logic for? To me it would seem to mean that the PR achieves only a slightly clearer error message, which I don't think is what we want.
"is deprecated; use out=keyword or np.maximum.reduce."); | ||
PyErr_Format(PyExc_TypeError, | ||
"np.maximum() takes exactly 2 input arguments (%zd given).", | ||
len_args); |
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 doesn't make sense to warn and error. You should just give the warning and test it. A warning can be turned into an error, in which case yuo need extra logic.
} | ||
/* otherwise, if this is np.maximum, raise */ | ||
else if (ufunc == UFUNC_MAXIMUM) { | ||
PyErr_WarnFormat(PyExc_DeprecationWarning, 1, |
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.
Can use DEPRECATE
macro, also should include the deprecating NumPy version in the message and as a comment above, like /* DEPRECATED NumPy ..., 2025-... */
attempts to resolve #27639