Thanks @ntessore for opening this discussion. Given the usage frequency, I agree this would be somewhat disruptive. The current state is:

• It's deprecated in 2.0, with removal probably having a long-ish timeline,
• The recommended replacement is scipy.stats.trapezoid,
• If a new dependency on scipy wouldn't be feasible, the implementation (which is basic and pure Python) could be vendored fairly easily.

An alternative is to keep it but rename it. For the majority of usage I think it's the same, since most projects and end user code is already going to rely on scipy. For the rest, they'd have more work if they decided to vendor the code to avoid a new dependency.

I'm not opposed to adding trapezoid. I am curious why it is used so much, given that it's somewhat inaccurate "area under curve given by samples" approximation, and for example scipy.integrate.simpson would usually be more accurate. Perhaps because it's good enough in many cases, and also because users see this function more prominently (simpson is not present in numpy after all). Scope wise I think it was a pretty random choice a long time ago to add this one function.

Let's see what others think.

Thanks for your reply @rgommers. Let me address the one point that I can:

I am curious why it is used so much, given that it's somewhat inaccurate "area under curve given by samples" approximation

I use the trapezoidal rule as my go-to because the only generic assumption that I am willing to make about sampled data is that it is sampled finely enough for a piecewise linear approximation to be "good enough". The trapezoidal rule implements this assumption, while anything beyond that is, in some sense, "augmentation" of the data. In my work, I am usually integrating data I have sampled myself, and it is hence usually always possible for me to push the sampling into that "linear is good enough" regime.

There other reasons for choosing the trapezoidal rule (e.g. when the given data needs resampling, and the piecewise linear approximation allows you find additional sampling points without changing the result of the quadrature), and there are reasons when the trapezoidal rule is actually the method of choice (some oscillatory integrals). I don't think these "informed choices" are reasons to keep the function around. Instead, I would argue firmly along the lines of: here is a simple quadrature method that makes the minimal amount of assumptions about the data, and in many (most?) cases its error can be pushed below any desired tolerance.

some oscillatory integrals

In particular, the dft :)

Discussed in the community meeting today: we'll put it back in as trapezoid. The argument of @ntessore is compelling enough, we don't want to cause too much disruption here by having folks need SciPy for this.

The error message will mention both trapezoid and that scipy.integrate has more methods for this.

Thanks for taking the time to consider this issue!