On Fri, Jun 19, 2015 at 9:30 AM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:

On 18.06.2015 14:27, josef.pktd@gmail.com wrote:
>
>
> On Thu, Jun 18, 2015 at 6:16 AM, Julian Taylor
> <jtaylor.debian@googlemail.com <mailto:jtaylor.debian@googlemail.com>>
> wrote:
>
> On Wed, Jun 17, 2015 at 10:44 PM, Abraham Escalante
> <aeklant@gmail.com <mailto:aeklant@gmail.com>> wrote:
> > Hello all,
> >
> > As part of the ongoing scipy.stats improvements we are pondering the
> > deprecation of `stats.threshold` (and its masked array counterpart:
> > `mstats.threshold`) for the following reasons.
> >
> > The functionality it provides is nearly identical to `np.clip`.
> > Its usage does not seem to be common (Ralf made a search with searchcode; it
> > is not used in scipy as a helper function either).
>
> I don't think those are sufficient reasons for deprecation.
> It does fullfil a purpose as its not exactly the same np.clip, the
> implementation is simple and maintainable and its documented well.
> There has to be something bad or dangerous about the function to
> warrant issuing warnings on usage.

Those are not the only possible reasons for deprecation. In this case it's a function that doesn't really fit in scipy.stats and seems to have become a public function only by accident. The goal here, like for multiple other recent deprecations, is to make scipy.stats a coherent package of statistics functions that are well documented and tested. In this case docs/tests are OK but the function simply doesn't belong in Scipy.

> I pretty much share the view of David, It has interesting use cases but
> it's not worth it.

I don't see the cost in keeping it, but the cost of removing it is
unknown. Just because we can't find any users does not mean they don't
exist.

You could make that argument about any deprecation.

While the Scipy deprecation policy is similar to Numpy, this kind of case is the main difference in my opinion. There's a reason Scipy still has an 0.xx version number.

Ralf