[SciPy-User] scipy.optimize named argument inconsistency

[Ralf Gommers]

On Tue, Sep 6, 2011 at 7:16 PM, Christopher Jordan-Squire
<cjordan1 at uw.edu>wrote:

> On Tue, Sep 6, 2011 at 12:08 PM, Ralf Gommers
> <ralf.gommers at googlemail.com> wrote:
> >
> >
> > 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
> >
>
> Is there a natural place to put some documentation for any new
> scipy.optimize argument conventions? It'd be great to have them
> written down so people that want to contribute down the line don't
> accidentally use non-standard names.
>
> A page under the "Development Plans" on http://projects.scipy.org/scipyseems like the place to put it until this is completed. Eventually the
unified interface should probably be described in
http://docs.scipy.org/doc/scipy/reference/optimize.html

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