[SciPy-user] Re: [SciPy-dev] Future directions for SciPy in light of meeting at Berkeley

Prabhu Ramachandran prabhu_r at users.sf.net
Wed Mar 9 05:24:42 CST 2005


Hi Travis,

>>>>> "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
    TO> infrastructure.

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
    fields.

 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
algorithms?  

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 me.

[...]

    TO> 2) Installation problems -- I'm not completely clear on what
    TO>    the
    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
convenience issue.

[scipy-sub-packages]

    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
    TO> infrastructure.

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
solution. :)

regards,
prabhu



More information about the SciPy-user mailing list