[SciPy-Dev] usage of inspect.getargspec ?

Nathaniel Smith njs@pobox....
Fri Jan 6 00:34:06 CST 2012

On Thu, Jan 5, 2012 at 9:15 PM, Travis Oliphant <travis@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?

-- Nathaniel

More information about the SciPy-Dev mailing list