[SciPy-Dev] usage of inspect.getargspec ?

[josef.pktd at gmail.com]

On Fri, Jan 6, 2012 at 9:41 AM, Travis Oliphant <travis at continuum.io> wrote:
>
>
> --
> Travis Oliphant
> (on a mobile)
> 512-826-7480
>
>
> On Jan 6, 2012, at 12:34 AM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> On Thu, Jan 5, 2012 at 9:15 PM, Travis Oliphant <travis at continuum.io> wrote:
>>> What is an isn't Pythonic seems to be a matter of some debate.     I *really* like the idea of unifying those arguments.   That simplifies the interface considerably.
>>
>> Yes, I try not to throw around "Pythonic" as an argument, since it
>> tends to turn into a slur rather than an argument. But this just
>> strikes me as so fundamentally at odds with Python's conventions that
>> I'm not sure what else to say.
>>
>>> I can understand the argument that it would be better to be explicit about it however.    I see a couple of options:
>>>
>>>        1) add a property to the function to indicate what kind of function it is --- a simple 'kind' attribute on the function
>>>        2) wrap up the function as the callable of a Singleton Class --- one kind for each "type" of function call.
>>
>> I'm honestly baffled at how any of this would simplify the interface
>> at all. We have two types of callbacks that might optionally be
>> passed, and they have totally different calling semantics. The
>> simplest way to represent that is to have two optional arguments. If
>> we shove them both into one argument but still have two types of
>> callbacks and then add some extra (possibly unreliable) machinery to
>> disambiguate them, then isn't that more complicated, not less?
>>
>> The original API:
>>  behavior 1: optimize(f, hess=f_hess)
>>  behavior 2: optimize(f, hessp=f_hessp)
>> The getargspec API:
>>  behavior 1: optimize(f, hess=f_hess)
>>  behavior 2: optimize(f, hess=f_hessp) # don't worry, we'll always guess right!
>> The property API:
>>  behavior 1 : optimize(f, hess=f_hess)
>>  behavior 2: f_hessp.kind = "hessp"; optimize(f, hess=f_hessp)
>> The class API:
>>  behavior 1: optimize(f, hess=f_hess)
>>  behavior 2: optimize(f, hess=this_is_really_a_hessp(f_hessp))
>>
>> How are the other options simpler than the first?
>
> This would be done most easily with a decorator when the function is defined, of course.   Also, the automatic discovery mechanism will work in most simple cases.  The decorator could be used in more complicated situations.
>
> Also it should be emphasized that this change is in the context of optimization unification.  Giving the main interface 2 Hessian arguments makes that function more confusing to new users who mostly won't need to deal with Hessians at all.  So, I like this change because it simplifies things mentally for more than 99.9% of the users while all the concerns are about possible complexity or confusion are for less than .1% of the users of the main function. Confusion which can be alleviated with decorators.
>
> My view is that simple things should be simple --- especially for the occasional user.

Sorry but I completely disagree.

99.9% of the users, to take your number, won't care, because they are
accessing the function through another library like statsmodels.

The change is mainly for the internal underlined function, the current
fmin_ncg stays unchanged.

For developers it makes the usage of the scipy optimizers a lot more
difficult because of the additional fragility of the implementation.

I think wrappers like curve_fit are good additions for occassional
users, but for statsmodels for example I don't want to have to worry
about whether getargspec correctly interprets our signature, or have
to jump through hoops to work with possible work-arounds.

Josef




>
> Travis
>
>
>>
>> -- Nathaniel
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev