[SciPy-dev] Technology Previews and Sphinx Docstring Annotations

[Charles R Harris]

On Tue, Nov 4, 2008 at 6:25 PM, David Cournapeau <cournape at gmail.com> wrote:

> On Wed, Nov 5, 2008 at 7:34 AM, Anne Archibald
> <aarchiba at physics.mcgill.ca> wrote:
> > 2008/11/4 Travis E. Oliphant <oliphant at enthought.com>:
> >> Jarrod Millman wrote:
> >>> I absolutely agree with the ideas presented about scikits and look
> >>> forward to seeing the numerous scikits improvements.  I feel that I
> >>> have gotten into a discussion where the counter argument to what I am
> >>> proposing is something I strongly support.  I also feel that the
> >>> counterargument doesn't directly address my concern; but it may be
> >>> that I am simply perceiving a problem that no one else believes
> >>> exists.
> >>>
> >> Let me make my point again.   I'm arguing that instead of scipy.preview,
> >> let's just make a *single* scikit called scikit.preview or
> >> scikit.forscipy or scikit.future_scipy or whatever.    This will create
> >> some incentive to make scikits easier to install generally as we want to
> >> get the future_scipy out there being used.
> >>
> >> I'm very interested, though, to hear what developers of modules that
> >> they would like to see in SciPy but have not made it there yet, think.
> >>
> >> I'm very interested in the question of how do we make it easier to
> >> contribute to SciPy.
> >
> > As a developer who has written the module that is sparking this
> > discussion, if the route to inclusion in scipy were "make a scikit,
> > maintain and distribute it until you get enough user feedback to judge
> > whether the API is optimal, then move it fully-formed into scipy" my
> > code would simply gather dust and never be included. I don't have the
> > time and energy to maintain a scikit.
>
> That's what I don't understand: there is almost no difference between
> maintaing a scikit and a scipy submodule. In both case you have to
> write some setup.py + the module itself. To get the sources, it is
> scikit vs scipy svn. Both Damian and you made this case, so I would
> like to understand what's so different from your POV, because I just
> don't get it ATM. Maybe there are some confusion on how a scikit can
> be made and distributer (the documentation could certainly be
> improved).
>

I think we could make a distinction between pure python/C code without
dependencies, and code that needs to deal with fortran compilers or library
deficiencies. For the former, a simple setup.py using distutils should do
the job and once that is in place it shouldn't be difficult to maintain. For
the latter, inclusion in scipy proper might be the better route.


> Having a scikit also means that if you are willing to do it, you can
> easily build binaries installers, source distributions *in one
> command*. You  can't do that with scipy, which won't change for the
> foreseable future. And you don't need to care about breaking scipy.
>

Agree.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20081106/de35b60a/attachment.html>