[Numpy-discussion] adding a .M attribute to the array.

Konrad Hinsen hinsen at cnrs-orleans.fr
Tue Mar 19 03:09:02 CST 2002


a.schmolck at gmx.net (A.Schmolck) writes:

> > > feature aspirations and divisions of labor of numpy/numarray and scipy are
>     ^^^^^^^
> Darn, I made a confusing mistake -- this should read _future_.

Or perhaps __future__  ;-)

> I personally agree with all your above points -- if you have a look at our
> "dotblas"-patch mentioned earlier (see [1]), you will find that it aims to do

And I didn't know even about this...

> It is however inconvinient for the maintainers. Whether one should bother
> including it in this or some other way depends, among the obvious question of

There could be two teams, one maintaining a standard portable
implementation, and another one taking care of optimization add-ons.
>From the user's point of view, what matters most is a single
entry-point for finding everything that is available.

> The monolithic approach is not entirely without its charms (remember
> python's "batteries included" jinggle)? Apart from convinience

Sure, but... That's the standard library. Everybody has it, in
identical form, and its consistency and portability is taken care off
by the Python development team. There can be only *one* standard
library that works like this.

I see no problem either with providing a larger integrated
distribution for specific user communities. But such distribution and
packaging strategies should be distinct from development projects. If
I can get a certain package only as part of a juge distribution that I
can't or don't want to install, then that package is effectively lost
for me. Worse, if one package comes with its personalized version of
another package (SciPy with NumPy), then I end up having to worry
about internal conflicts within my installation.

On the other hand, package interdependencies are a big problem in the
Open Source community at large, and I have personally been bitten more
than once by an incompatible change in NumPy that broke my modules.
But I don't see any other solution than better communication between
development teams.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------




More information about the Numpy-discussion mailing list