Upfront disclaimer: like I said yesterday, I wrote those e-mails when
my frustration with a number of things completely boiled over. Then I
just core dumped everything that was bothering me into the mails.
Probably the only thing that's useful beyond the scope of the specific
problems I was experiencing are my comments about unused keyword
arguments.
Gripe #3 is related to interactive windows when Python and the X11
server are connected by a slow link.This is a consequence of how most of the interactive backends are
implemented.
...
Implementing the backends using their built in plotting commands
may be a way around this, but it means having much higher maintenance
costs for backends and lots of annoying capability mismatches (some
backends don't support rotated text, alpha blending, etc.)
I figured it was something like this, and I can understand that the
benefits of a common rendering engine outweigh the admittedly small
benefit of fast remote X11 redraws. Furthermore I've more or less
solved the problem for myself by using non-interactive backends with a
combination of scripts and ssh tunnels that watch for changes in a
file on the remote machine and, when it is modified, sends the file
over the link, where (similarly) a script is watching for changes in
the _local_ file and lauches a viewer. Not sure why this seems to
make a difference (all the pixel data is going over the channel in
either case) but it seems to make a big difference.
* John Hunter <jdhunter@...8...> wrote:
> Gripe #2 is that it would be nice if the same word were
> abbreviated the same way everywhere. Ie, either cmap or cm,
> not both.
I don't think I agree with you here. matplotlib.cm is a *module* and
cm is a convenient reference to that module for pylab interactive
users who want to save on keystrokes. I think it would lead to
confusion and hard to find bugs if a module name and a kwarg were the
same.
Not sure why this is the case. I realize that they're different
entities in the language, but they both help you with the same task.
Context always (?) allows the Python interpreter to know the
difference, and the exceptions that are thrown by problems with each
are different. As a user, the thought that goes through my head when
I'm using either one is "Something related to colormaps" and there's
an extra cognitive load associated with remembering that "Modules
related to colormaps" requires cm while "Arguments related to
colormaps" requires cmap.
I don't see this as a huge problem since a simple pcolor?
in ipython would have shown you the correct kwarg.
True, but we're aiming high here. If I didn't care about things like
this, I'd use Fortran or C because everyone else does and I certainly
wouldn't have taken an interest in Python. If you can just guess
without referring to documentation and have software do what you want,
I think that's a sign of an elegant interface: it has anticipated my
desires.
And if mpl had raised an exception on seeing cm as a kwarg as you
suggest in gripe#1, it wouldn't have been a problem for you.
Quite true! The extra cognitive load would still be there, but
addressing grip #1 effectively would make this into a very small
annoyance rather than something that can cause real frustration.
So in the near future, we may have a GTK backend that uses native
drawing and looks good too. In which case you may get speed over an
X11 connection as well as nice looking plots.
This sounds great. 
> Not everyone uses matplotlib inside of scripts! Judging
> from the manual, this is the only approved way to use the
> library.
If the manual gives a different impression, that is unintentional,
and may result from selective reading.
...
Basically, the claim that we only support a scripting interface is
not true.
I didn't mean to imply that this was a policy decision, only that it
seems to be an assumption that's made often in the manual.
Specifically the thing that set me off was what I referred to here:
> Looking through the manual, I
> find that I can specify it on the command line, in
> .matplotlibrc, or via matplotlib.use('..'), but only "before
> you import matplotlib.pylab"
I couldn't figure out why matplotlib.use(...) didn't seem to be doing
anything, and then I found the bit about it only working before you
import matplotlib.pylab. This is where my frustration boiled over,
and I dashed off the e-mail. That probably wasn't a great idea
(writing while angry) but what can I say? All of this together set me
off.
matplotlib development usually happens when a developer needs a
feature or one or more users make a case that a feature is important
-- you are officially the second person to request the ability to
switch backends interactively, if memory serves.
I'm certainly open to the idea of contributing code, but at this point
I'm obviously not in a position to do so since I'm still learning my
way around. Also, I can see that interactively switching
backends will be a seldom used feature. My desire for it (and
excessive frustration when I failed to find it) were due to an unhappy
confluence of events.
that. As you'll see in that thread, Fernando is looking into ways to
include the backend switching functionality into ipython, eg so you
can run a script withrun -backend PS somefile.py
It's true that this is done from an interactive Python shell, but I
wouldn't call this switching backends interactively. In general my
.py files contain only function definitions. So I would envision
being able to do things like this:
%run defs.py
z = read_data()
make_plot(z)
switch_backend('PS')
make_plot(z)
Now, please keep in mind my comments above: that once I use mpl a
little more and establish a regular pattern of use, I don't expect
to need this feature much, if at all. I'm just commenting on the
example you gave.
But even w/o this ease of use, in the current matplotlib release the
pylab switch_backend function exists.
Cool, I'll certainly give it a shot.
Thanks,
Greg
ยทยทยท
* Perry Greenfield <perry@...86...> wrote: