[SciPy-User] scipy.optimize named argument inconsistency

[Christopher Jordan-Squire]

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.

-Chris

>
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
>