Scientific Libraries in Python

[Fernando Pérez]

Horatio Davis wrote:

 
> Having read this excellent mud map of the problem space, and the
> followups, I'd like to add my my $0.01 (would be $0.02 but the exchange
> rate on the Aussie dollar is fairly embarrassing right now).

[snip]

Thanks for the compliment. In return, you did what I didn't finish: a good 
update of the graphical tools (I forgot scigraphica in my first draft) and a 
decent summary.

I fully agree with you at this point. In the graphing dept, I don't mind 
having separate 2d/3d tools (scigraphica and mayavi), that may even be an 
asset. But it would be great if the two projects could keep an eye on each 
other so that they expose a similar scripting interface. It would be pain in 
the ass to have to remember completely different syntaxes for trivial things 
like setting a plot title depending on whether one is doing 2d or 3d. 

> 
> Numeric Python, of course, makes whichever list it feels like. (:
> 
> I've left it out of both lists because there's an announcement on the
> NumPy home page that it is being reimplemented from scratch by Perry
> Greenfield and company. This looks (to my untrained eye) like they're
> going ahead with the Numeric 2 proposed in PEP 209, and are going for
> inclusion in the Python standard library. Implications for the unified
> scientific library are left as an exercise for the reader. Could we have
> comments from anybody on that project team?

Very interesting... I hadn't seen this. I hope they can come through without 
too high costs in speed for smaller arrays (currently they only reach 1/2 
asymptotic throughput at >20k elements, which may be too slow for many 
applications).

> Now... licensing. While the top two projects are both less...restrictive,
> I reluctantly have to concede that these lists have an awful lot of GPL
> code that would be difficult or impossible to do without. The eventual
> license, therefore, looks like GPL or (if we're lucky) LGPL. I can even
> live with that if it'll get me a coherent scientific library, but others
> might have a different viewpoint. What would those viewpoints be?

At this point we need to hear from the  code owners, who are ultimately the 
ones who will have to make those decisions.

There does seem to be a lot of interest from many into a saner organization 
of python's scientific abilities. I hope the scipy folks are reading this and 
can incorporate some of these comments/suggestions into their project. And 
again, I think your summary has a very good layout of what's needed to 
minimize duplication of effort and having something fully useful *soon*.

Cheers,

f.