[SciPy-Dev] preparing for scipy 0.8 release

Ralf Gommers ralf.gommers@googlemail....
Mon Apr 26 06:41:07 CDT 2010

On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen <pav+sp@iki.fi<pav%2Bsp@iki.fi>
> wrote:

> Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote:
> > Now that scipy 0.7.2 and numpy 1.4.1 are out the door, it's time to look
> > at what needs to be done for scipy 0.8.
> >
> > Some questions
> > - What needs to be done and what do you all want included that's not in
> > trunk yet in terms of features / new code / code cleanups?
> I have these on my platter:
> * http://github.com/pv/scipy-work/tree/superlu-update
>  SuperLU 4.0, which includes support for incomplete LU decompositions,
>  which at least I've been really missing in Scipy.
>  New feature: scipy.sparse.linalg.spilu
>  Needs just some tests, otherwise done. So if someone wants to test it
>  or write some tests exercising splu and spilu, that'd be helpful!
> * http://github.com/pv/scipy-work/tree/ticket/791-optimize-nonlin-rewrite
>  New feature: scipy.optimize.nonlin rewrite
>  Quite done, and with tests. However, scipy.optimize line searches take
>  a ~20% performance hit because of the way I refactored them. If this
>  doesn't sound good, I can try to rework it still more.
> * Might be also nice to fix the remaining most serious scipy.special
>  bugs.

So merging/fixing this in the next month is feasible for you?

> > - Right now scipy trunk needs to be built against numpy trunk. Is it
> > feasible to build against numpy 1.3 still, to get one
> > backwards-compatible release?
> > If not, 0.8 should be released in parallel with numpy 2.0. - Time line:
> > do we want a release before SciPy2010 (end of June)? If so, there's only
> > a month left before a freeze. If not, we could just provide snapshot
> > binaries in June.
> As David said, we'll need at least Numpy >= 1.4, due to use of npymath.
> It might be difficult to go for Python 3 support if we want to have
> backwards compatibility with Numpy 1.4, unless we go really ugly and
> start duplicating some of the utility functions inside Scipy. But from a
> maintenance POV that might be less of a burden than having to maintain
> 0.8.x and 0.9.x simultaneously...
The number of fixes in the 0.7 series is small, so I'm not sure if the
maintenance burden is really that high (besides possibly having to do an
extra maintenance release). It depends on how long you'd want to keep
compatibility with numpy 1.4. Anyway, both options sound better than having
no compatible release at all.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20100426/21962f52/attachment.html 

More information about the SciPy-Dev mailing list