[SciPy-dev] Future directions for SciPy in light of meeting at Berkeley
prabhu_r at users.sf.net
Wed Mar 9 05:24:42 CST 2005
>>>>> "TO" == Travis Oliphant <oliphant at ee.byu.edu> writes:
TO> I was looking to try and understand why with an increasing
TO> number of Scientific users of Python, relatively few people
TO> actually seem to want to contribute to scipy, regularly, even
TO> becoming active developers. There are lots of people who seem
TO> to identify problems (though very often vague ones), but not
TO> many who seem able (either through time or interest
TO> contraints) to actually contribute to code, documentation, or
I think there are two issues here.
1. Finding developers. Unfortunately, I'm as clueless as anyone
else. It looks to me that most folks who are capable of
contributing are already occupied with other projects. The rest
use scipy and are quite happy with it (except for the occasional
problem). Others are either heavily invested in other solutions,
or don't have the skill or time to contribute. I also think that
there are a fair number of users who use scipy at some level or
another but are quiet about it and don't have a chance to
contribute. From what I can tell, the intersection of the set of
people who possess good computing skills and also persue numerical
work from Python is still a very small number compared to other
2. Packaging issues. More on this later.
TO> I think the answers come down to a few issues which I will
TO> attempt to answer with proposals.
TO> 1) Plotting -- scipy's plotting wasn't good enough (we knew
I am not sure what this has to do with scipy's utility? Do you mean
to say that you'd like to have people starting to use scipy to plot
things and then hope that they contribute back to scipy's numeric
If all they did was to use scipy for plotting, the only contributions
would be towards plotting. If you only mean this as a convenience,
then this seems like a packaging issue and not related to scipy.
Plotting is one part of the puzzle. You don't seem to mention any
deficiencies with respect to numerical algorithms. This seems to
suggest that apart from things like packaging and docs, the numeric
side is pretty solid.
Let me take this to an extreme, if plotting be deemed a part of
scipy's core then how about f2py? It is definitely core
functionality. So why not make f2py part of scipy? How about g77,
g95, and gcc. The only direction this looks to be headed is to make a
SciPy OS (== Enthon?).
I think we are mixing packaging along with other issues here.
To make it clear, I am not against incorporating matplotlib in scipy.
I just think that the argument for its inclusion does not seem clear
TO> 2) Installation problems -- I'm not completely clear on what
TO> "installation problems" really are. I hear people talk about
TO> Proposal (just an idea to start discussion):
TO> Subdivide scipy into several super packages that install
TO> cleanly but can also be installed separately. Implement a
TO> CPAN-or-yum-like repository and query system for installing
TO> scientific packages.
What does this have to do with scipy per se? This is more like a user
TO> I haven't fleshed this thing out yet as you can tell. I'm
TO> mainly talking publicly to spur discussion. The basic idea is
TO> that we should force ourselves to distribute scipy in separate
TO> packages. This would force us to implement a yum-or-CPAN-like
TO> package repository, so that we define the interface as to how
TO> an additional module could be developed by someone, even
TO> maintained separately (with a different license), and simply
TO> inserted into an intelligent point under the scipy
This is in general a good idea but one that goes far beyond scipy
itself. Joe Cooper mentioned that he had ideas on how to really do
this in a cross-platform way. Many of us eagerly await his
More information about the Scipy-dev