Scientific Libraries in Python
horatio at qpsf.edu.au
Tue Nov 27 00:55:42 CET 2001
On 26 Nov 2001, Prabhu Ramachandran wrote:
> > VTK (Martin et al) - 3D visualization on GTK - personal copyright
> Well, I guess that is a typo but FWIW I'd like to mention that VTK
> does not depend on GTK and does not use it at all.
Quite so, it is a typo. That's what I get for posting from a Microsoft
machine late at night. (:
> Thanks for the compliments on MayaVi. :)
My thesis topic is in computer-mediated technical collaborations,
specifically collaborative scientific visualization. My Sinister Ulterior
Motive (TM) is that when I get around to implementing my ideas, I would
like to do it in Python. The presence of so much good-quality scientific
code gives me hope I can do that; if I can get at it in one place easily,
I can concentrate on the computer science instead of reinventing the
wheel. If not... there are fallback plans involving Java and Matlab, C and
Octave, because I really am here to do research, not hack. It is my hope I
won't have to use them.
> That is why I chose the GPL. However, the GPL does force everyone
> else who links to it to be GPL. I guess LGPL might also work but I
> really don't know.
Thanks for considering this idea.
> Anyway, I am not sure you want to put all packages into one huge super
> package. It would be a nightmare to package/distribute! I'd really
> pity the person who'd have to maintain such a beast.
Distutils are your friend. (: As for maintainers, one of the better ways
of handling this is for everyone involved to pile on to scipy.org, each
maintaining the code they brought to the party. The initial assimilation
phase would indeed be painful, but once all the namespaces and package
structures and the like were unified, the pain would subside.
Where there are existing projects, such as MayaVi or Scigraphica, the core
library would include them as opt-in parts - much like the current Numeric
treats FFTW or LAPACK, and as Scientific treats Numeric. So long as the
relevant maintainers are at least talking to each other (and the core
library maintainers shoulder the responsibility of writing any
impedance-matching code) it's all good.
More information about the Python-list