[SciPy-User] scipy.optimize named argument inconsistency

[Ralf Gommers]

On Tue, Sep 6, 2011 at 5:46 PM, <josef.pktd at gmail.com> wrote:

> On Tue, Sep 6, 2011 at 10:53 AM, Denis Laxalde <denis.laxalde at mcgill.ca>
> wrote:
> > I'm glad to see that several people agree on this topic. I will then
> > work on standardizing names and orders of parameters and returns
> > as well as possible grouping (e.g. for solver statistics).
> >
> > On Mon, 5 Sep 2011 09:23:41 -0400,
> > josef.pktd at gmail.com wrote:
> >> It might be a bit messy during deprecation with double names, and
> >> there remain different arguments depending on the algorithm, e.g.
> >> constraints or not, and if constraints which kind, objective value and
> >> derivative in one function or in two.
> >
> > I guess the case input parameters could be treated by adding new
> > parameters and pointing old ones to the latter with a warning. But what
> > about returns? For instance, how should one deal with changes of order
> > or parameters being grouped with others?
> >
> > In general, I have little knowledge concerning deprecation mechanisms so
> > any advice (or documentation/example pointer) would be welcome.
>
> One possibility, that has been used in numpy.histogram, is to add a
> "new=False" or "new=True" keyword, to switch behavior during
> transition.
>

This may apply to a few cases where the outputs should be reshuffled or
changed, but we should try to minimize "new=" - it requires the user to
change his code twice because eventually the new keyword should also
disappear again. The histogram change didn't go very smoothly imho. If the
changes are large, another option is to just deprecate the whole function
and write a new one with the desired interface. That would just require a
single change for the user. It does depend on whether a good new name can be
found of course.

For renaming of input parameters (both positional and keyword), just do the
rename and then add the old name as a new keyword at the end. Then document
in the docstring that it's deprecated, and check for it at the beginning of
the function and if used do:
warnings.warn("<informative message>", DeprecationWarning)
The message should also state the scipy version when it was deprecated (0.11
probably) and when it will disappear (0.12).

Could you make an overview of which functions should be changed, and your
proposed new unified interface? The best solution could depend on the
details of the changed needed.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20110906/500755e6/attachment.html>