Re: Deprecating numpy.fix

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]