[PYTHON MATRIX-SIG] plotting software

[Geoffrey Furnish]

Phil Austin writes:
 > >>>>> "JWE" == John W Eaton <jwe@bevo.che.wisc.edu> writes:
 >     JWE> A similar library that is distributed under the GPL is
 >     JWE> plplot, but I'm not sure that it is being actively maintained
 >     JWE> these days.
 > 
 > Lack of a good free plotting package is a sticking point for several
 > numerically-oriented interpreted languages.  There has been some
 > discussion of this on the Numeric Python mailing list as well, and
 > perhaps a group effort spanning Octave, Python, Perl data language,
 > etc. could produce something.  We'd like to see the most portable
 > possible solution, and the Tk driver in Plplot shows promise in that
 > direction, although the move of Geoff Furnish, the Plplot maintainer,
 > from Livermore to Los Alamos may have derailed that (there was also
 > some talk several months about about merging Plplot with gist, a
 > free Livermore graphics package that runs on X under Yorick or
 > Python).  One person on the Python list is writing plotting software
 > in Java to run under Python (see http://estel.uindy.edu/PESSci/ph280/)

I can only speak for PLplot.  It has been mentioned here several times
in the last few months.  I have twice composed responses and then
deleted them instead of sending them.  I'll try again now.

Bottom line:  PLplot's Python support does and will continue to exist,
and will even continue to improve.  I am using Python and PLplot in my
work, past, present, and future, and PLplot will continue to improve
as a consequence.  

I have been extremely reticient to chime in with info about PLplot on
the Python Matrix SIG over the last few months specifically because I
am absolutely sick to death of Pythonians publicly maligning PLplot
for its allegedly poor autoconf support, whilst never bothering to
carefully document their problems and provide them to the PLplot
mailing list where the PLplot maintainer (me) or other PLplot hotshots
(of whom there are several), might have a fighting chance of helping
them.  The list of the guilty here is long and grievous, and I am
really sick of it.

I am especially sick of the misplaced condemnation.  Writing autoconf
support is *hard* and the Python community seems to be somewhat unique
among autoconf users in terms of their oblivion to the issues,
apparently specifically b/c Python's "auto"-conf doesn't
"automatically" configure very much at all (it checks the system OS
characteristics in order to configure the supported Python modules
which interact with the OS, but it does not do any meaningful search
for auxilliary packages a user might have installed).  With Python you
have to manually configure practically everything, which is /much/
more burdensome on the user than is PLplot.  The problem is that
autoconf isn't perfect.  It is at best an asymptotically converging
system.  For 99% of all installed computers systems, autoconf does a
fantastic job.  For 1% of the installed computers, the sysadmins have
succeeded in so incomparably screwing things up that autoconf can't
sort it out, and the users on these systems invariably blame the
package maintainer.  For instance, at my previous place of employment,
the installation of X on a particular computer that I used a lot, was
so perniciously mishandled that no autoconf version from 2.4 through
2.10 could /automatically/ recognize that the system had X.
Fortunately autoconf suports user overides, and I was abble to pass
configure the --x-includes=/where/they/actually/were flag, to overcome
this annoyance.

PLplot has drawn an extremely disproportionate amount of criticism
from one community--the Python community--for its allegedly
insufferable configuration support.  I will be the first to admit that
PLplot's autoconf support has required a lot of attention.  Many many
bugs were fixed over the summer/fall '96 timeframe.  There were
PLplot snapshots to provide many of these improvemtns to external
PLplot users.  I do still have additional fixes which have not yet
been propagated to an externally accessible snapshot.  There will be
more PLplot snapshots, and when they show up, people will be able to
benefit from the improvements which have been made.

I cannot schedule these.  I am not paid to hack PLplot.  I am paid to
do science, and I hack PLplot only in so far as it is undeniably
justifiable in the pursuit of my mandated job functions.  As with all
GPL'd software, it is possible to obtain professional support for
PLplot.

Besides the autoconf issues with PLplot, Pythonians have also
complained regularly about uneven support for a dynamically loadable
Python extension module for PLplot.  Again, it is no trouble to
compile PLplot with -fpic or the equivalent for your compiler.  There
are, however, major issues to be addressed in terms of the total
python integration picture.  I certainly view the Python module import
system as very primitive, and nowhere near as sophisticated as that
seen in certain other scripting environments, and have the very strong
sensation that this is poorly appreciated in the Python community.
Python extensions composed of /both/ Python source /and/ compiled
extensions, are not well served by simply "import"-ing a dynloadable
module, since it may be necessary to simultaneously update the
PYTHONPATH to find the *.py files that go with the .so.  Support for
this kind of thing is very poor in Python.  The PLplot approach to
dealing with this is to favor static builds.  Moreover, it is also
very hard to support dynloading of PLplot in combination with its Tk
support, because of the poor design of the tkinter module.  I have
found it exceedingly hard to build a Python which seemlessly supports
dynloadable tkmodule with selective inclusion of Tcl extension
modules.  The -DWITH_APPINIT thing is woefully inadequate in the face
of the sort of freewheeling dynloadable extension style that Python
seems to want to encourage.

The last time these issues were discussed in this forum, the moderator
told us to quit talking about it, even though the discussion followed
directly from issues relating to numeric plotting extensions, which
are surely germane to this list, and also even though the NumPy
extension itself suffers from many of the same issues.  I am flatly
exasperated by the Python community with respect to the prevailing
sentiments about PLplot, and the deafening silence that has followed
is a direct reflection of this exasperation (rather than an indication
that PLplot is currently unsupported).  This message is very much an
attempt to bring some closure to the matter in this forum.  I do not
intend to go out of my way to publicize PLplot's Python support to the
Python community in the future.  I will publicize PLplot's Python
support to the PLplot community.

As a final reference to Phil's comments about a multi-script-language
plotting library, let me just say the following:

PLplot has long aimed to provide the same plotting library across
every interesting programming architecture.  This started with support
for multiple compiled language interfaces (fortran, C and C++), and
has proceeded also to cover multiple script languages (Tcl, Scheme,
Python).  Perl-dl hasn't been done yet, but it surely will someday.
Same for Java--it's not on the calendar, but it is surely going to
happen one of these days.  PLplot is already bound to packages like
Ocatve and Rlab, and similar such support from other packages is
inevitable.  Bottom line, if you are a PLplot user, and you start
working in a new environment one day, hopefully you will find that
PLplot is already there, or can be taken there easily.  This has been
an enduring characteristic of PLplot for many years, and will continue
irrespective of the prevailing mood of the Python community.

Cheers,
-- 
Geoffrey Furnish                email: furnish@lanl.gov
LANL CIC-19 POOMA/RadTran       phone: 505-665-4529     fax: 505-665-7880

"Here are your ball-peen hammers.  Now go malleate some heads!"   -Jim Morel

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

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