[SciPy-dev] toward scipy 1.0
Pierre GM
pgmdevlist at gmail.com
Tue Nov 4 19:20:54 EST 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