[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