>>>>> "Chris" == Chris Barker <Chris.Barker@...> writes:
Chris> Why use nx, rather than n? (or N, which is what I usually
Chris> use). Actually, I usually use "import Numeric as N", I used
Chris> 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.
Chris> I'd say that this decision should be driven somewhat by
Chris> what you want matplotlib to be. I see it as a plotting
Chris> package, and I see Numeric (or SciPyBase?) as a numerical
Chris> array package. Given that, option (1) is the way to go.
Chris> However, I can see the strong appeal of an all in one
Chris> package, al la Matlab. If we go this route (which is kind
Chris> of the route at the moment), we'll see lot of questions on
Chris> this list that have nothing to do with matplotlib, and
Chris> everything to do with Numerix. WE have that already, of
Chris> I really would like to see a nice, unified, set of packages
Chris> for doing scientific/numeric work with Python. I think
Chris> SciPy is the natural place for this, NOT matplotlib. My
Chris> ideal version would have matplotlib as a sub-package of
Chris> SciPy. It looks like we get to the grand-unification of
Chris> Numeric, as SciPy Base, that that's a good start. I don't
Chris> recall why you didn't make matplotlib a subpackage of SciPy
Chris> 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 :-)
Chris> that way, and honestly, there have been a lot of "plotting
Chris> for SciPy" starts, and none of them has gotten to the
Chris> usefulness of matplotlib, so you certainly did something
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.
Chris> I just looked in the class docs, and I still can't see how
Chris> to set something in an OO way, like the facecolor, for
Chris> x.set('facecolor', 'r') maybe?
Chris> I know I'd rather x.SetFaceColor('r') or something like
Chris> that, but the above is OK too.
All matplotlib properties work this way:
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
which has the advantage of supporting multiple property names
x.set(facecolor='red', linewidth=2, alpha=0.5)
Chris> Well, yes, for embedded use, but for quick scripts and
Chris> interactive use, there should gbe an OO way to have your
Chris> 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
Chris> It's probably time for me to put up or shut up...I hope
Chris> I'll get a chance to put up soon.
Chris> Maybe a good start would be to go through the tutorial and
Chris> users guide, and try to re-write all the examples in an OO
Chris> manner, and see what happens.
Sounds like as good an idea as any.