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

Matthew Brett matthew.brett at gmail.com
Thu May 27 20:17:28 EDT 2010


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.

See you,

Matthew



More information about the SciPy-Dev mailing list