[SciPy-dev] a modest proposal for technology previews

David Cournapeau david@ar.media.kyoto-u.ac...
Tue Nov 4 02:36:28 CST 2008

Jarrod Millman wrote:
> The major difference I see is that one is a scikit and the other is
> part of scipy. 

Yes - and that's exactly why I think it is good to use scikits for that
:) If you put things in scipy.preview:
    - what happens when the build breaks on common platforms ?
    - what happens when you want to work in a manner which is not
synchronized with scipy release process ?

The only advantage of scipy.preview I can see is that it is a easier to
get the code for scipy users (hence my discussion about scikits build
management). I don't think it outweights the disadvantages.

Here is how I would see the process:
    - you start coding your scikit
    - once you have something, you discuss it on the ML, and you say you
want it to include for scipy (here we can put any requirement: decent
doc, testsuite, etc...)
    - if the consensus is that it can be included, then put it somewhere
in scipy

As you see, there is almost no difference compared to putting it into
scipy.preview from the code review process. BUT, during the dev process,
it can break scipy build, may not buildable on the platforms we usually
support, etc... The whole code process not happening in scipy.preview
has a lot of advantages.

>  In my mind, for something to be part of scipy means
> that it should fit into the package in a consistent way.  If I was
> developing a scikit, I don't think I would necessarily write it the
> same way as if I was trying to make it part of scipy.

I don't understand this: it just means you have to think that it can go
into scipy when you develop your scikit. How would the code would be any
different is it was developed under scikits or scipy.preview ? The only
difference for the source is that the namespace and the svn repository
is different.



More information about the Scipy-dev mailing list