On Sat, Nov 8, 2025 at 12:15 PM sebastian <[email protected]> wrote:
> 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... > I agree with this concern. It's not *that* much and the code is trivially fixable by replacing `fix` with `trunc`. So a slow deprecation with removal in a 3.0 release would already be quite conservative compared to our normal deprecation policy. We don't need to make a special exception and keep an alias around forever without documenting it. Cheers, Ralf
_______________________________________________ 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]
