[Numpy-discussion] Hello and my first patch
oliphant at ee.byu.edu
Thu Oct 5 14:53:58 CDT 2006
John Hunter wrote:
>>>>>>"Robert" == Robert Kern <robert.kern at gmail.com> writes:
> Robert> IMO, I'd rather see this and similar functions go into
> Robert> scipy. New functions that apply semantics to arrays (in
> Robert> this case, treating them as time series), I think should
> Robert> go into scipy. New functions that treat arrays simply as
> Robert> arrays and are generally useful can probably go into
> Robert> numpy.
>I prefer Perry's longstanding suggestion: things that do not add to
>distribution complexity should go into numpy. If it compiles as
>easily as numpy itself, it should go into numpy where sensible.
I don't think this is as feasible as it sounds at first. Some people
complain that NumPy is too big already.
SciPy is very easy to install on Windows (there is a binary available).
The only major platform that still gives some trouble is Intel Mac (due
to the fortran compiler situation). But, all you need is one person
who can build it and distribute a binary.
I think a better long-term solution is to understand how to package
things better by working with people at Enthought so that when you
advertise to the ex-Matlab user you point him to a "super-package" that
installs a bunch of other small packages. This is a more maintainable
solution as long as we set standards for
3) some kind of problem-domain hierarchy
The idea of just lumping more an more things into NumPy itself is not a
good idea. What most users want is something that installs easily (like
Enthon). How it is packaged is not as important. What developers need
is a sane multi-namespace system that can be maintained separately if
I think we decided a while ago, that the package approach should contain
indicators as to whether or not a fortran compiler was needed to build
the system so that dependency on those things could be eliminated if
Do we want to pull scipy apart into two components: one that needs
Fortran to build and another that doesn't?
Perhaps that is the best way to move forward along with the work on a
More information about the Numpy-discussion