I'm off with family for the holidays, so my response will have to be somewhat
brief.
I'm excited about the ideas you bring up... I first heard about sympy at SciPy
and was very impressed. Let's try to collaborate in any way possible. I know
that "3D in matplotlib" already has some history of which I'm not aware, so I'll
leave that for others to comment on.
As for the C++ dependencies, Agg is a pretty strong one. Yes, it is possible to
do rendering with Gtk or Wx alone, but it's not very pretty (no-aa). Gtk/Cairo is
a good high-quality combination, but it (at least currently) leaves out all the
other GUI frameworks, and is not BSD-like licensed. The other important
C/C++ requirement is matplotlib's interface to freetype (FT2Font). That would
be really painful to reimplement in pure Python -- freetype is a complex and
mature piece of software. In the trunk, there is a required framework for
transformations, and in the "transforms branch" there is a framework for
polycurve manipulations, both of which are required to do any plotting. Those
would have a major performance penalty going to Python, and even
notwithstanding, are non-trivial bits of code to reimplement. Beyond that, there
are utilities for contours and images etc., which are reasonably optional but
people use all the time. In short, there's a not of C/C++ in the core of
matplotlib -- maybe the time would be better spent resolving any build issues
that make portability difficult...? I'm not sure it's realistic to expect matplotlib to
be pure Python at this point without losing a lot of features, but I agree it would
be nice...
As for the mathtext Python math rendering engine, it isn't *really* pure Python.
It relies on matplotlib's interface to Freetype. Ideally, it would be nice to have a
general-purpose Python interface to freetype (I know the PyCairo folks are
wanting such a thing), and then the mathtext engine could use that.
Unfortunately, the existing freetype wrapper in matplotlib is very incomplete
and pretty tied to matplotlib-specific ways of doing things. IMHO, you wouldn't
really gain much by releasing FT2Font as a separate project unless it were
generalized. I've sort of gone into a holding pattern, hoping someone else will
release a Python freetype wrapper that matplotlib could use... Alternatively, the
dependency on freetype could be removed by extracting and hardcoding all the
font metrics from the math fonts into Python dictionaries etc. -- but then of
course it would only work with a fixed set of fonts. This is what jsMath, (a
pure-Javascript math rendering engine) does, for instance.
With the exception of that issue, removing the mathtext engine from matplotlib
should be possible, and I think it's a great idea. There are some matplotlib-
specific bits mixed in there, but they should be reasonably straightforward to
factor out. It already has support for rendering math to an in-memory image
bitmap, which has been used for displaying math on GUI widgets, for example.
Anyway -- cool ideas. Let's keep up the discussion.
Cheers,
Mike