On 2025-11-07 02:58, Stefan van der Walt via NumPy-Discussion wrote:
On Mon, Nov 3, 2025, at 12:29, Nathan via NumPy-Discussion wrote:
Ralf rightly pointed out
(https://github.com/numpy/numpy/pull/30098#pullrequestreview-3408343827)
that np.fix does have substantial downstream usage and that a
deprecation needs to go through the mailing list, so I'm raising
this here.
I see 9.2k files showing up in the GH search results, so in this
instance I'd say it's OK to remove it from the public namespace to
discourage use, but we probably shouldn't get rid of it? Perhaps just
reimplement it using np.trunc and leave it in place indefinitely?
I agree it's reasonably common, although e.g. a specialized
`np.quantile` has 56k
and the similar but more typical `np.ceil` has 389k files.
From the search I also feel it is far more common in scripts then
libraries, both
pywt/sklearn have it yes, but only in a single corner of their API (and
many
other large packages don't).
How slow/soft do we really want to be for this in the future for
somewhat common
but not really very common things?!
Ralfs concerned was about libraries. I am happy to just wait for 2.5
there is no reason
not to and we have an explicit downstream request to do so, and we
should always honor that.
But I actually don't think there would have been anything wrong with
just going ahead here.
The whole point of a 1-year deprecation policy is that it gives
skimage/pywt one year to
notice the warning and avoid it. During that time end-users will not
see the warning
at all (unless it comes from their own code). [1]
End-users nuisance/general churn is a bigger concern and I guess we
could decide to just
soft-deprecate for that reason.
(I do think this is noisy/low impact enough to take it slowly, maybe
very slow.)
But honestly, I hate to use this as a precedence and honestly the worry
seems a bit
out of proportion to the actual impact?
As a point of references, `np.trapz` does have a deprecation warning and
it has
35.6k files in a github search!
If we worry about `np.fix` being too much (in itself) then it seems a
bit like we might
end up in a place where every deprecation is a big decision...
Cheers,
Sebastian
[1] Yes, there are transient CI issues for libraries that a downstream
library causes
the warning. But I think we are used to ignoring warnings like this in
CI.
Stéfan
_______________________________________________
NumPy-Discussion mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3//lists/numpy-discussion.python.org
Member address: [email protected]
_______________________________________________
NumPy-Discussion mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3//lists/numpy-discussion.python.org
Member address: [email protected]
