[SciPy-dev] toward scipy 1.0

Pierre GM pgmdevlist@gmail....
Tue Nov 4 18:20:54 CST 2008


All,
I'm not really involved in the development of scipy, so I don't expect my 
opinion to matter much.

Still, I'm getting a bit frustrated with Scipy at the moment: it looks like 
the release of 0.70 has been postponed month after month since spring because 
of some blocking tickets in modules I have little to no use for. It's hard to 
explain to some colleagues of mine that they can't use the scikits.timeseries 
package because it relies on a couple of functions that are not part of any 
official release yet.

If we're going to reorganize scipy, I'd be pretty much in favor of modularity: 
let me install just the packages I need (scipy.stats, scipy.special, 
scipy.whatever) without bothering about the ones I'll never use. 

Breaking scipy into smaller packages sounds a lot like scikits, but is it that 
bad a thing ? Would it make development more difficult ? Would it make 
installation and maintenance more complex ? As long as there's one standard 
for setup.py, things should go OK, shouldn't they ? Because they'd be part of 
scipy and not a scikit, the different modules would have a varnish of 
stability that the scikits don't necessarily have, and it might simplify the 
transformation of a scikit to a scipy module.

As you'd have guessed, I'm all in favor of a kind of central repository like 
cran or ctan. Each scikit could come with a few keywords (provided by their 
developer) to simplify the cataloguing, and with a central page it shouldn't 
be that difficult to know what is being developed and at what pace, or even 
just what is available. It might reduce the chances of duplicated code, help 
future developers by providing some examples, and generally be a good PR 
system for scikits/scipy packages... And yes, why not using some kind of 
graphical brwser ?

Now, of course, I'll go with the flow no matter what...



More information about the Scipy-dev mailing list