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

[Warren Weckesser]

David wrote:
> On 05/28/2010 07:20 AM, Matthew Brett wrote:
>   
>> Hi,
>>
>>     
>>> 1. Fix it and deprecate it.
>>> 2. Deprecate it, but don't bother fixing it.
>>> 3. Remove it without bothering with a cycle of deprecation.
>>>       
>>> My initial preference was for #3, but David C. suggested sticking with
>>> the deprecation policy, which is fine with me.  I'll just remove it next
>>> week, after 0.8 is branched, so it will be gone in 0.9.  So, revision
>>> r6416 assumes #2.
>>>       
>> The deprecation would be because someone may have been using it, and
>> they would be surprised to see it has gone, and that surprise would
>> seem to them to be a flaw in scipy.  We want to avoid that.
>>
>> 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.
>>     
>
> There is no way to gauge the unlikeness, and I think as a developer, you 
> almost always underestimate the cost. Maybe some users have a 
> monkey-patch version of the module, who knows.
>
>   
>> 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'm perfectly happy with deprecating, for all the reasons Robert and 
David have mentioned.


> It does not to me. Keeping python code has *no* cost from a maintainance 
> point of view (contrary to compiled code which may be a pain to allow it 
> to build),


Since you specifically emphasized "no", I will respectfully disagree 
with you about that.  I spent time fixing a bug in ppimport, before I 
knew that it was deprecated and no longer had a use in scipy--and that 
it had additional problems besides the small ones I fixed.  My questions 
about ppimport took up time of other developers.  Developers' time is a 
cost.  Code that is not going to be maintained, or that no longer solves 
a problem within the scope of SciPy, should be removed.

But not until is has been deprecated for at least one release. :)

Warren


>  so there should be a really good reason to *remove* it, not a 
> good reason to *keep* it.
>
> cheers,
>
> David
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>