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

[David]

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?

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), so there should be a really good reason to *remove* it, not a 
good reason to *keep* it.

cheers,

David