[SciPy-dev] Scipy workflow (and not tools).
Wed Feb 25 13:30:03 CST 2009
On Thu, Feb 26, 2009 at 4:22 AM, Charles R Harris
> On Wed, Feb 25, 2009 at 11:58 AM, Matthew Brett <email@example.com>
>> >> Tests protect the user and the developer alike. It is irresponsible
>> >> to carry on the way we do.
>> > No it's not.
>> Scipy is rarely released. David and Stefan are saying that it is very
>> hard to release.
>> It might be true, that continuing with the organic, 'add it if it
>> seems good' approach, will be fine. But it might also be true that
>> it will make Scipy grind to a halt, as it becomes too poorly
>> structured and tested to maintain.
>> rates Numpy / Scipy / matplotlib as 'immature'. This is mainly
>> because of Scipy, and it's fair. It we want it to change we have to
>> be able to release versions that have good documentation and low bug
>> The choices we make now are going to have long-lasting consequences for
>> I think our best guess, from what David and Stefan are saying, that we
>> need a change towards more structured process. I stress the word
>> "need". This doesn't seem surprising to me. I think we've got to
>> listen to them, because they are doing the work of maintaining and
>> releasing Scipy.
> Much of Scipy *isn't* maintained, that is why it is immature. There are
> parts that need to be worked over and rationalized and that isn't happening.
> You can't review code that hasn't been written. Some of that is history: the
> initial impetus in Scipy was interfacing existing C and Fortran libraries
> with Python and scratching itches. But that isn't the same as putting
> together a large package with smoothly interacting parts and verified
> results. And before that can happen we need more people working on the
Also, if the problem is man power, adding more code which makes the
whole package more difficult to handle does not sound like a future
proof path. Unless the goal of scipy is to become a bag of tricks
which may be useful to some people, without any commitment from our
Some parts of scipy are difficult to maintain because they have no
tests and no documentation - it is not even obvious what it is
supposed to do. I am afraid we can't have it both ways: if we want to
increase quality, given man power, we have to reduce the amount of
code which requires constant attention. If we want more features
first, then, we can continute like we do now. But then we can't expect
constant releases, which are relatively well tested.
More information about the Scipy-dev