[SciPy-Dev] On deprecating `stats.threshold`

[Abraham Escalante]

I think we should move forward with the deprecation since `np.clip` pretty
much covers this and as Ralf points out, the function doesn't seem to fit
in `scipy.stats`.

It would make more sense for `np.clip` to be enhanced with the option to
use the same value to substitute anything below and above the limits,
although that would be outside the scope of this project. It may be a nice
addition.

Regards,
Abraham.

2015-06-21 9:52 GMT-05:00 Ralf Gommers <ralf.gommers at gmail.com>:

>
>
> On Fri, Jun 19, 2015 at 9:30 AM, Julian Taylor <
> jtaylor.debian at googlemail.com> wrote:
>
>> On 18.06.2015 14:27, josef.pktd at gmail.com wrote:
>> >
>> >
>> > On Thu, Jun 18, 2015 at 6:16 AM, Julian Taylor
>> > <jtaylor.debian at googlemail.com <mailto:jtaylor.debian at googlemail.com>>
>> > wrote:
>> >
>> >     On Wed, Jun 17, 2015 at 10:44 PM, Abraham Escalante
>> >     <aeklant at gmail.com <mailto:aeklant at 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
>
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150625/738db043/attachment.html>