[SciPy-User] return "full_output" or how to stop throwing away already calculated results

Rob Falck robfalck@gmail....
Tue Mar 9 21:37:32 CST 2010

Returning an object would be my preference as well, it seems more
pythonic.  Most optimizers should be able to return at a minimum


Some optimizers have other useful data to return, such as the Lagrange
multiplers from slsqp.  Going down that path means probably breaking
current implementations of the optimizers, but doing it right would be
worth it, in my opinion.  We should also agree upon names for the
common attributes.

On Tue, Mar 9, 2010 at 8:56 PM, David Warde-Farley <dwf@cs.toronto.edu> wrote:
> On 9-Mar-10, at 4:01 PM, josef.pktd@gmail.com wrote:
>> in statsmodels, I am switching more to the pattern when
>> full_output=True (or similar keyword) for a function, then all
>> intermediate results are returned, attached to a generic class
>> instance ( or could be a struct in matlab or a bunch for Gael,...)
> David Cournapeau pointed out (in the thread "anyone to look at #1402?"
> on the numpy-discussion list) that the wider Python community frowns
> on the type of the returned value depending on a boolean flag
> argument, preferring instead different function names that call some
> common (private) helper function. It provided some validation for my
> uncomfortable feelings about scipy.optimize methods that do this.
> I do think it's worth thinking about returning some sort of proxy
> object that can have attributes set to either 'None' or the
> appropriate values. It would certainly make code more readable (except
> in the situation where you use argument unpacking, but even then it
> isn't obvious to an outsider how crucial that full_output thing is).
> David
> _______________________________________________
> SciPy-User mailing list
> SciPy-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user

- Rob Falck

More information about the SciPy-User mailing list