A few comments:
John Hunter wrote:
> I have no problem with this. I think we should agree on a standard
> way of writing examples. I'm of two minds about how we should do this
> vis-a-vis numerix symbols.
> Approach 1: Help educate newbies about where symbols are coming from
> import pylab as p
> import matplotlib.numerix as nx
> x = nx.arange(100.0)
> y = nx.sin(2*nx.pi*x)
> Approach 2: Given that the array packages are still being reorganized,
> use pylab as a namespace aggregator
> import pylab as p
> x = p.arange(100.0)
> y = p.sin(2*nx.pi*x)
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.
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
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 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!
> 1 looks better to me for the standard symbols (arange, pi, etc...) but
> when you start to include linear algebra, FFT, MLab, etc, I am not
> sure. Currently mpl numerix uses the numarray hierarchy: is there any
> advanced word on whether this will be used in Numeric3?
I haven't noticed, but I'm guessing it'll be something like:
import scipy.fft as fft
> Basically, the question is, do we want to encourage using pylab as a
> namespace aggregator to hide the complexity of where all these symbols
> are coming from in packages whose organization is still evolving?
I'd say no, but you're point about the still evolving is a good one.
> Also, I still want to support the 'from somewhere import something'
> style of import since I think it makes the scripts more friendly to
> read for many from a procedural programming background..
> from pylab import hist, show
Sure. I do this a fair bit. I like it because it is explicit about where
stuff is coming from. You're also right, if you are using a procedural
style, typing "pylab." all the time gets pretty tiresome.
> Chris> One way to get there is to add much of the functionality of
> Chris> pylab to the OO interface. I really wish I had the time to
> Chris> write an OO-pylab, I think it would be really great, even
> Chris> for interactive use.
> I think the OO interface is already pretty easy to use.
It may have gotten better. I haven't use it much recently, my main
matplotlib using project has been handed off to another coder. I just
remember that as much as I wanted to use the OO interface, It ended up
being much easier to use pylab.whatever much of the time. Maybe the real
problem isn't what's there, but what's in the examples.
> * Easier attribute setting (eg x.facecolor = 'r') but this is
> already accomplished somewhat since the set/get introspection
> facilities are now available in matplotlib.artist to the OO user
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.
> * Have some way to enable auto-redraw on attribute change for
> interactive use. This could be accomplished fairly easily with an
> ipython hook
That would be nice. Having to call Figure.show() isn't too bad though.
> * Make the backend figure canvas, figure import a little less wordy,
Yes. What I'd like to be able to do is:
import matplotlib as mpl
F = mpl.Figure()
A = F.plot(x,y)
The only convenience you'd lose over the procedural interface is the
"current figure/axis" concept, which I don't like much anyway.
> Are there other areas you would like to see improved? There isn't a
> lot pylab does anymore, except manage the figure windows. And
> usually the API developer wants to do this in any case.
Well, yes, for embedded use, but for quick scripts and interactive use,
there should gbe an OO way to have your figure windows managed.
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.
Christopher Barker, Ph.D.
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception