[SciPy-Dev] Design of scipy.stats

[David Goldsmith]

On Thu, May 20, 2010 at 2:00 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Thu, May 20, 2010 at 14:03,  <josef.pktd at gmail.com> wrote:
> > On Thu, May 20, 2010 at 2:53 PM, David Goldsmith
> > <d.l.goldsmith at gmail.com> wrote:
> >> So then that's actually the one that should be documented?  Or they both
> >> should?  (Forgive me if I sound ignorant, but I'm not familiar w/ this
> API
> >> model: I'm use to the library/package/module providing the class, as in
> >> "class library," and then the user instantiating (or sub-classing) that
> as
> >> s/he needs; I've never heard of an "instance library.")  Thanks again!
> >
> > the docstrings are attached to or generated for the classes. The
> > instances get the docstrings from the class, and don't have separate
> > docstrings.
> >
> > The instances are created for convenience (especially for users who
> > are not familiar with classes).
>
> Not really. It was just the best way to implement the features at the
> time with the minimum of duplicated code. I'm pretty sure it was
> designed before class methods were introduced. The original design
> also did not have the frozen distributions; __call__ was an alias to
> .rvs(). The distribution objects act like functions with additional
> methods, much like ufuncs do. It's just that now they act more like
> factory functions (or class objects) than most normal functions so
> things get a little confusing.
>

Ah, now I understand ("factory functions" *are* something I've heard of, and
vaguely understand...)  IMO, we're going to have to explain all this (and
better) somewhere (stats.distributions looks like a good place) if for no
other reason than Robert says "things get a little confusing" (I'm sure he
isn't confused, but when Robert acknowledges that something isn't obvious,
to me that means it's *far* from obvious) ;-)

UNLESS...

If we were to design the system with the tools we have available
> today, it would be designed quite differently, I expect.
>

...IIRC, from time to time there's chatter about re-factoring scipy - is it
safe to assume that *if* such ever happens, *then* re-factoring this module
is likely to be high on the priorities list?


> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100520/164b58c8/attachment.html>