Why use nx, rather than n? (or N, which is what I usually
> use). Actually, I usually use "import Numeric as N", I used
> Numeric long before I discovered matplotlib.
In my own scripts, I often use N to be the size of something. And I
eschew capital letters for ease of typing. I prefer nx since it
doesn't clash with many current scripts, is easy to type, and
resonates with the current name numerix which for better or worse is
the name mpl has used for Numeric/numarray integration. I'm not wed
to "nx" though.
> I'd say that this decision should be driven somewhat by
> what you want matplotlib to be. I see it as a plotting
> package, and I see Numeric (or SciPyBase?) as a numerical
> array package. Given that, option (1) is the way to go.
> However, I can see the strong appeal of an all in one
> package, al la Matlab. If we go this route (which is kind
> of the route at the moment), we'll see lot of questions on
> this list that have nothing to do with matplotlib, and
> everything to do with Numerix. WE have that already, of
> course.
> I really would like to see a nice, unified, set of packages
> for doing scientific/numeric work with Python. I think
> SciPy is the natural place for this, NOT matplotlib. My
> ideal version would have matplotlib as a sub-package of
> SciPy. It looks like we get to the grand-unification of
> Numeric, as SciPy Base, that that's a good start. I don't
> recall why you didn't make matplotlib a subpackage of SciPy
> in the first place, but I can understand that it happened
The historical reason was that scipy was considered hard to install.
matplotlib was pure python until 0.5 or something like that, and
depended only on Numeric and pygtk. Now mpl is fairly hard to install
and much more elaborate, and scipy is getting much easier to install.
If and when the time is right, and the powers that be want to integrate
mpl with scipy, I am happy to do it. I've also raised objections in
the past on the grounds that mpl release schedules are much faster
than scipy release schedules, but we're starting to get slow and
crotchety in our old age around here as well 
> that way, and honestly, there have been a lot of "plotting
> for SciPy" starts, and none of them has gotten to the
> usefulness of matplotlib, so you certainly did something
> right!
Thanks. I think the key is a relentless focus on making plots "look
good" and supporting all the reasonable features that people need.
That's what drove me away from other alternatives, at least. I mean,
as a self respecting open source/scientific python zealot, you're
nowhere if your plots look like crap.
> I just looked in the class docs, and I still can't see how
> to set something in an OO way, like the facecolor, for
> example:
> x.set('facecolor', 'r') maybe?
> I know I'd rather x.SetFaceColor('r') or something like
> that, but the above is OK too.
Use
x.set_facecolor('r')
All matplotlib properties work this way:
OBJECT.set_PROPNAME(VAL).
You should also be sure get your hands on a recent version of ipython;
TAB completion is your friend. In mpl CVS, in response to this
thread, I also added support for
x.set(facecolor='r')
which has the advantage of supporting multiple property names
x.set(facecolor='red', linewidth=2, alpha=0.5)
> Well, yes, for embedded use, but for quick scripts and
> interactive use, there should gbe an OO way to have your
> figure windows managed.
This sounds like what I call "pythonic matplotlib": using the pylab
interface to manage the GUI windows and such, while retaining a
pythonic coding style; eg, not relying on the current figure and axes
state. See examples/pythonic_matplotlib.py
> It's probably time for me to put up or shut up...I hope
> I'll get a chance to put up soon.
> Maybe a good start would be to go through the tutorial and
> users guide, and try to re-write all the examples in an OO
> manner, and see what happens.
Sounds like as good an idea as any.
JDH