Re: [Matplotlib-users] Keyword Parameters

[John H. <jdh...@ac...>]

>>>>> "Greg" == Greg Novak <no...@uc...> writes:

    Greg> This is gripe #1: weak typing only works when using
    Greg> undefined variables bites you on the nose.  Otherwise we're

This is a good point -- Norbert submitted a patch addressing this a
couple of months ago but it broke python2.2 so we unrolled it.  I've
added it to my list of things to do.  It's tricky to get right, but
it's manageable and important.

    Greg> Gripe #2 is that it would be nice if the same word were
    Greg> abbreviated the same way everywhere.  Ie, either cmap or cm,
    Greg> 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.  Now cm may not be the best module name, perhaps cmaps would be
better.  I don't see this as a huge problem since a simple 

  >>> pcolor?  

in ipython would have shown you the correct kwarg.  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.

BTW, do you know you can interactively change the colormap for an
existing plot with the jet, gray, hot, et al commands

  >>> pcolor(rand(12,12))  # use your default colormap
  >>> hot()     # colormap is now hot
  >>> summer()  # colormap is now summer

    Greg> Gripe #3 is related to interactive windows when Python and
    Greg> the X11 server are connected by a slow link.  All of the
    Greg> interactive backends I've used for matplotlib look great,
    Greg> but render very slowly in this situation b/c they're sending
    Greg> all the pixel data.  Since most plots consist of a few
    Greg> lines, a bit of text, and a few dots, it'd be nice if the
    Greg> windows rendered quickly over slow connections.  For
    Greg> example, Gnuplot runs very well in this configuration.  I
    Greg> realize that this doesn't invovle matplotlib per se, I just
    Greg> wanted to throw it out there as a concern.

Perry already addressed this -- basically because we have so many
python GUIs it becomes a maintenance nightmare to add new features if
we use native drawing.  Using agg to render to a bitmap which is then
transferred to a GUI canvas means we can add a feature in one place
and Tk, Wx, GTk, Fltk and QT users automagically get it with *no*
changes to the GUI backend.  It comes with a cost, as you observed.

You do have the option of using a GUI native drawing backend, eg GTK
instead of GTKAgg or WX instead of WXAgg.  Because we use double
buffering in GTK, it may not help (Steve -- would it be possible to
make double buffering optional?)  The native GTK drawing is inferior
to Agg, in my view, but you may be willing to trade quality for
speed.  

There is hope for you, however, that you can have the best of both
worlds.  Steve says that GTK is moving to a Cairo renderer for GTK
2.8, which does provide nice graphics.  And it is a happy confluence
of circumstances that 1) matplotlib has a Cairo backend, 2) the GTK
maintainer (Steve Chaplin) is also the author of the Cairo and
GTKCairo backends and 3) Steve is very good about keeping the GTK*
stuff up to the latest developments in the gtk world.  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.

    Greg> I apologize for the negative tone of this mail.  Don't get
    Greg> me wrong--I use matplotlib and I like it b/c it's the best
    Greg> thing I've found.  However, I just had one of those
    Greg> "GAAARGHGGHHHH!" moments and it's taking a little while to
    Greg> de-stress.

No problem.  With all the fan mail we're getting around here, we're
starting to get a little soft :-).  Some well placed criticism keeps
us on our toes.

Thanks,
JDH