[SciPy-dev] a modest proposal for technology previews

Nathan Bell wnbell@gmail....
Wed Nov 5 12:15:12 CST 2008

On Wed, Nov 5, 2008 at 11:53 AM, David Cournapeau <cournape@gmail.com> wrote:
> Except it doesn't. Putting it into scipy does not make it magically
> built and released. Again, the last release of scipy was in september
> 2007. As I pointed out previously, putting code into scipy makes it
> *more* difficult to distribute, at least in practice.

Well, that's (1) not true today since 0.7 is due and (2) another
problem that needs to be addressed (e.g. by moving to a 6 month

> If scipy were released regularly, then I would at least understand the
> argument (I would still be against, though). But it isn't. And adding
> code means it takes even more time to get it out. One more package
> does not make much difference. But this just cannot work as a general
> process, not without scaling the man power for scipy.

As I see it, scipy.spatial:
- has an API that was discussed publically
- has a comprehensive set of unit tests
- has an active maintainer

Furthermore, the release of SciPy 0.7 *is* imminent, and not a year or
more away.

Let's not argue abstract cases anymore.  The worst case scenario is
that the spatial module requires modest API changes in a subsequent
release.  Anne has done due diligence in soliciting ideas and feedback
from the mailing list, so I doubt these will upset people.  Also, the
only way to expand spatial's userbase in a meaningful way *today* is
to put spatial in scipy proper.

I don't fundamentally disagree with the concerns that have been laid
out w.r.t. stability.  At the same time, I don't think we have the
luxury or the right to set arbitrarily high standards for inclusion of
code into scipy.  We should not forget that a significant part of why
people contribute to scipy (esp. the mundane tasks) is the implicit
promise that their work will be visible.  Scikits does not yet meet
this standard.

Let's release SciPy 0.7 (w/ spatial) ASAP and then look towards making
scikits a more viable alternative.

Nathan Bell wnbell@gmail.com

More information about the Scipy-dev mailing list