[MATRIX-SIG] [long] A NO-Proposal for a plot-package

[Konrad Hinsen]

David Ascher:

> This would take over matrix-sig's role as the place to ask questions about
> numpy?

Yes.

> > - Create separate mailing lists (not formal SIGs) for communication
> >   between the people working in specific code, e.g. plotting or
> >   array indexing.
> 
> Why not make them sigs?  The administrative burden is basically the same
> whether it's a sig or some other mailing list, and this way they get
> visibility on python.org, archival, etc.  

I have the impression that creating a SIG is a rather complicated
process, whereas I can start a mailing list on Starship by just
typing a few commands. But that's the only reason, I have nothing
against SIGs in principle!


Geoffrey Furnish:

> You want to just relabel matrix-sig as sci-sig?  And generalize the
> charter?

Either that or create a new SIG and let the old one die a few months
later. I don't know which is easier to do.

> I do not favor non-sig mailing lists for discussion of major
> subsystems.  They are not really very open for people to
> subscribe/unsubscribe, since one has to bother a person instead of a
> daemon.  One of the best things about a sig is that people can get on
> and off without having to ask for help.  Also, such ad-hoc lists are
> not archived.

I was thinking of MailMan-based mailing lists on Starship, which are
technically the same as the SIGs on python.org, but without any
formalities attached. I do agree that openness and archiving are
important.

> This sounds a little to me like the presumption of the one true
> python-centric solution mentioned previously.  This is arguably

Not "the one true" but "a good and easy-to-use one".

> reasonable for a direct language facility like the matrix stuff, but I
> think it is basically misplaced loyalty when applied to non-language
> intrinsic facilities.  For instance, there is no "one true python

I think plotting is at the borderline. For standard tasks an interface
to existing plotting packages is fine, but a Python implementation 
gives me the opportunity to modify a plot variety by subclassing in
Python. Since it seems that the major complaint about plotting package
X is "it doesn't have feature Y which I need urgently", I am inclined
to put a high value on this customizability.

In addition, there is the installation complexity problem posed by
external packages. To my surprise I received quite a few complaints
about my Molecular Modelling Toolkit related to its use of netCDF.
There were no real problems about netCDF, and installing it is a
simple task, but the simple fact of having to read another README and
running another set of tests seems to put off some people. NumPy
of course is bad enough (but will hopefully change), but at least
Python/C module combinations all work in much the same way.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________