[Numpy-discussion] Future directions for SciPy in light of meeting at Berkeley

Bruce Southey southey at uiuc.edu
Wed Mar 9 07:24:29 EST 2005

I fully agree with these comments but I think there is a user experience aspect   
as well. This is my little rant (if you want) as a different view because I  
really do appreciate the scientific python community. Please understand that 
these are issues that I see as problems and do not reflect any negative view of 
what is available. 
The basics of Python and numarray (and Numeric almost to the same extent)   
already provide what most users need, basically the implementation of matrix   
algorithms.  I have not tried SciPy for some time so I really will not address  
it. So in one sense, what more is there to achieve? :-)  
For a user to contribute material there are some issues that I tend to think  
about. As you know, it is usually easier (and quicker with Python) to write  
your own code than try to adapt existing code (and the bloat issue with code  
that is unnecessary to the user needs). The second aspect is being able to   
contribute that code back into a package - usually this is too hard (coding   
styles etc.), may not have high programming experience to be able to achieve   
this and may not know how to contribute it in the first place.  This also gets 
problematic when items are passed to C or Fortran.    
My 'job' is not to develop packages but to get results (mainly statistics and    
bioinformatics). Any free time to do development is usually nonexistant (one    
has to write papers for example). I would guess that this is not uncommon for    
the scientific python users.     
A related issue is missing (or at least not obvious) and inflexible features.   
For example, I do statistics and missing (unobserved) values are a problem   
(cannot mix types or missing value code may actually occur). But I can use   
masked arrays (which really means numarray) to handle this rather nicely.   
I fully agree with others on directions. From a Python view, if "python 
setup.py install" doesn't work 'out of the box' then there are big problems.  
---- Original message ----     
>Date: Wed, 09 Mar 2005 17:32:15 +0900     
>From: Michiel Jan Laurens de Hoon <mdehoon at ims.u-tokyo.ac.jp>       
>Subject: Re: [Numpy-discussion] Future directions for SciPy in light of     
meeting at Berkeley       
>To: Travis Oliphant <oliphant at ee.byu.edu>     
>Cc: SciPy Developers List <scipy-dev at scipy.net>, scipy-user at scipy.net,     
numpy-discussion <numpy-discussion at lists.sourceforge.net>     
>Travis Oliphant wrote:     
>> It would seem that while the scipy conference demonstrates a continuing      
>> and even increasing use of Python for scientific computing,  not as many      
>> of these users are scipy devotees.   Why?     
>> I think the answers come down to a few issues which I will attempt to      
>> answer with proposals.     
>> 1) Plotting     
>While plotting is important, I don't think that SciPy needs to offer      
>plotting capabilities in order to become successful. Numerical Python      
>doesn't include plotting, and it's hugely popular. I would think that      
>installing Scipy-lite + (selection of SciPy-lib sub-packages) + (your      
>favorite plotting package) separately is acceptable.     
>> 2) Installation problems     
>This is the real problem. I'm one of the maintainers of Biopython      
>(python and C code for computational biology), which relies on Numerical      
>Python. Now that Numerical Python is not being actively maintained, I'd      
>love to be able to direct our users to SciPy instead. But as long as      
>SciPy doesn't install out of the box with a python setup.py install,      
>it's not viable as a replacement for Numerical Python. I'd spend the      
>whole day dealing with installation problems from Biopython users.     
>There are three other reasons why I have not become a SciPy devotee,      
>although I use Python for scientific computing all the time:     
>3) Numerical Python already does the job very well. There are few      
>packages in SciPy that I actually need. Special functions would be nice,      
>but it's easier to write your own module than to install SciPy.     
>4) SciPy looks bloated. It seems to try to do too many things, so that      
>it becomes impossible to maintain SciPy well.     
>5) Uncertain future. With Numerical Python, we know what we get. I don't      
>know what SciPy will look like in a few years (numarray? Numeric3?      
>Numeric2?) and if it still has a trouble-free installation. So it's too      
>risky for Biopython to go over to SciPy.     
>It's really unfortunate, because my impression is that the SciPy      
>developers are smart people who write good code, which currently is not      
>used as much as it could because of these problems. I hope my comments      
>will be helpful.     
>SF email is sponsored by - The IT Product Guide     
>Read honest & candid reviews on hundreds of IT Products from real users.     
>Discover which products truly live up to the hype. Start reading now.     
>Numpy-discussion mailing list     
>Numpy-discussion at lists.sourceforge.net     

More information about the NumPy-Discussion mailing list