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

Charles R Harris charlesr.harris at gmail.com
Thu May 27 22:19:08 EDT 2010


2010/5/27 Stéfan van der Walt <stefan at sun.ac.za>

> On 27 May 2010 17:28, Robert Kern <robert.kern at gmail.com> wrote:
> > 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.
>
> Sure, that makes sense except that the rule never envisioned this
> situation: deprecation of a broken function.  What do we do: raise a
> deprecationwarning and then proceed to let the broken code run?
> David's argument about monkeypatching also doesn't make much sense to
> me: if a user monkey-patched ppimport, how will deprecation help?
>
> If we deprecate, we have to fix the function to at least return a valid
> result.
>
>

How about a deprecation warning that also says the function is broken?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100527/fe9b1c11/attachment-0001.html>


More information about the SciPy-Dev mailing list