Hi, 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. Regards Bruce ---- Original message ----

Date: Wed, 09 Mar 2005 17:32:15 +0900 From: Michiel Jan Laurens de Hoon <mdehoon@ims.u-tokyo.ac.jp> Subject: Re: [Numpy-discussion] Future directions for SciPy in light of meeting at Berkeley To: Travis Oliphant <oliphant@ee.byu.edu> Cc: SciPy Developers List <scipy-dev@scipy.net>, scipy-user@scipy.net, numpy-discussion <numpy-discussion@lists.sourceforge.net>

...

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

Travis Oliphant wrote: 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.

--Michiel.

------------------------------------------------------- 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. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion