No subject


Thu Jun 29 11:59:23 CDT 2006


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 Scipy-dev mailing list