[SciPy-dev] ASP: Ipython in SciPy

Robert Kern rkern at ucsd.edu
Tue Nov 2 10:43:35 CST 2004

Joe Harrington wrote:
> Someone questioned why to put Ipython into scipy when it's easy for
> Linux users to install scipy and ipython separately.  However, that's
> true of several of our packages.  There are two reasons to include
> ipython:
> 1. The sense of the BoF was that the user docs should *only* describe
>    using Ipython, with the exception of a brief section describing how
>    to start and use plain Python.  It won't be discussed as an
>    optional thing, and the docs will make heavy use of its
>    capabilities.  We want to reduce the possibility of problems, and
>    since Ipython is not large or on a rapid development schedule, it
>    makes sense to include it.

As far as I can see, these decisions can be supported entirely by 
packaging and advertisement. Wedging IPython into the scipy source tree 
doesn't, to my eye, have any tangible benefits above that. Since IPython 
should always be available without scipy (I claim), we're always going 
to have two packages.

> 2. As Eric has stated in the past, scipy is supposed to be an
>    inclusive package, providing everything you need or would
>    reasonably want.  There are certainly other packaging philosophies,
>    but that's the one he's chosen for scipy. 

I think that statement is more true of Enthon than it is of scipy, the 
package, at least in the broad interpretation you are putting on it. I 
see scipy as being an inclusive *library* for doing scientific/numerical 
work. IPython is not, in its current form, a good library. It will be; I 
have that much faith in Fernando's abilities. It may make sense to 
revisit this question then.

> This makes a lot of
>    sense for Windows and other places where installing is a drag.
>    There are some exceptions, of course, such as things on a rapid
>    release schedule (like matplotlib) and specialized application
>    software, particularly the big stuff.  Excluding these is more of a
>    practical decision than a principled one.

I think scipy should be a good library for scientific work. I think 
IPython should be a good interactive environment and eventually a good 
library for building interactive environments.

One can make a good interactive environment for doing scientific work by 
using IPython and scipy together. One day, Envisage, Ipython, and scipy 
are all going to work together and then one will be able to make a good 
interactive GUI environment for scientific work.

But none of this requires that they all be part of the same package 
("package" as in "from scipy import linalg"). Enthon and other such 
packages ("packages" as in "apt-get install enthon") fill this role much 
better. They can also include all the pieces like pytables, ctypes, 
wxPython, Kiva, Chaco, Traits, Enable and the like that we *really* 
don't need to put under scipy.

Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

More information about the Scipy-dev mailing list