[SciPy-Dev] deprecations - things to remove before 0.8.0

[Robert Kern]

On Thu, May 27, 2010 at 20:17, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
>>> However, if it is broken, then it seems to me that the user will be
>>> more likely to think that the flaw is leaving in code that is broken.
>>>  It's also unlikely that anyone will be surprised to see it go if it
>>> hasn't worked for a long time.
>>>
>>> So - if it has not been working for at least one version, and we are
>>> not thinking of fixing it, I vote to remove.   Does that seem
>>> reasonable?
>>
>> I see no reason to break our deprecation rule. If it were actively
>> causing problems, like complicating the build, then that might be a
>> reason to break the rule. We shouldn't seek out excuses to break the
>> rule.
>
> Rules are for reasons.   The deprecation rule, I suppose, is to reduce
> surprise, by giving fair warning to people using features that will be
> removed.    My argument was from that point of view, but I may have
> misunderstood the reason for the rule.

The reason to *follow* a rule is not the same reason for *instating*
the rule. We should follow the rules that we have agreed to because we
should make good on our promises. Otherwise, we might as well not make
those promises and make just make deprecation/removal decisions on a
case-by-case basis all the time.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco