[SciPy-dev] change scipy.optimize function signatures?? FEEDBACK NEEDED!! (ticket 285)
Anne Archibald
peridot.faceted@gmail....
Thu Jul 19 10:36:12 CDT 2007
On 19/07/07, Alan G Isaac <aisaac@american.edu> wrote:
> For example, according to the ticket, the signature for brent would change from
> def brent(func, args=(), brack=None, tol=1.48e-8, full_output=0, maxiter=500):
> to
> def brent(func, args=(), brack=None, tol=1.48e-8, full_output=0, maxiter=500, bracket_keywords = {} ):
>
> In my personal view, this signature is already messy.
> If it is to grow an argument, I suggest that the argument
> be a parameters object.
>
> This would work something like the following.
> (No deep thought on this yet.)
>
> class OptizationParams:
> def __init__(self, **kwargs):
> self.set_defaults()
> for k,v in kwargs.iteritems():
> if hasattr(self, k):
> setattr(self, k, v)
> else:
> raise AttributeError
> def set_defaults(self):
> self.args = ()
> self.tol = 1.48e-8
> self.full_output=0
> self.maxiter=500
> self.bracket_interval = None
> self.bracket_grow_limit = None
>
> The signature for brent would become
> def brent(func, params=OptizationParams(), **kwargs):
>
> Any kwargs provided to `brent` would override the values in
> the OptParam instance. This should be fully backwards
> compatible and, looking forward, very flexible.
Please don't do this! This renders the signature useless in figuring
out how to call the function. This is something I really hate about
ufuncs, which don't even have useful docstrings. The issue is not that
the signature is changing - who cares? - but that the celling API is
changing. That's not something we can do much about; APIs do change.
Then again, I'm not sure I see what this opaque OptimizationParams is
supposed to accomplish. (Remember that you can, if you feel the urge,
call brent(F,x0,**optimization_parameters) even with the current API).
Anne
More information about the Scipy-dev
mailing list