Re: [Matplotlib-users] how to make matplotlib faster?

[Ted D. <ted...@jp...>]

John,
I think the push/pop functions are going to be fairly useful (ipush and 
ipop??).  We're going to be writing a lot scripts (i.e. functions) that 
generate plots for our users.  There is no way to tell inside the script if 
it's going to be used by a user in interactive mode or by another script 
(like a batch report generator).  Having push/pop would let me do:

def stdPlot( [inputs] ):
    ipush( False )
    try:
       [ create plot ]
    finally:
       ipop()

Of course it's pretty easy to roll your own but I think it would be nice to 
have it in the standard set of commands.

At 05:54 AM 12/12/2004, John Hunter wrote:
> >>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
>
>     Perry> In thinking about the ioff(), ion() approach it occurs to
>     Perry> me that it may not be quite so simple for scripts. I think
>     Perry> a common desire is for a script or function to turn off
>     Perry> interactive mode if it is on, but at the end, restore the
>     Perry> previous interactive state. In this case a push/pop
>     Perry> approach to interactive mode may be more appropriate rather
>     Perry> than stop/start. In particular, if interactive mode
>     Perry> happended to be off, you wouldn't want to turn it on at the
>     Perry> end of the script.
>
>BTW, Eric emailed me off list.  It appears that running his script in
>interactive mode was the root cause of his performance problems.
>
>In regards to running scripts from the python shell, I think the least
>invasive approach is to write a run function that stores the
>interactive state, calls ioff, runs the script with execfile, then
>calls ion (precisely what ipython does).  In fact, perhaps we should
>add a run function to the pylab interface which does just this.
>Fernando could simply override this function if he wants to do some
>additional ipython magic.  But this would wrap the logic for those who
>want to run scripts from the other python shell.  Of course it would
>only work for non-image backends and Tk, or GUI backends associated
>with a GUI shell like pycrust.
>
>I'm less worried about people inadvertently running scripts from the
>command shell with interactive set to True, because interactive
>defaults to False in rc and thus the person would have had to
>intentionally change it, at least at some point in dark history.
>Hence they are probably aware of it.  Singing the praises of ipython
>yet again, I leave the default in my rc to False, and run ipython when
>I want to work interactively, letting ipython turn interaction on for
>me. Thus I can run python somescript.py from the command shell assured
>that it is off, and still use matplotlib interactively w/o having to
>tweak the setting.
>
>But if there is some concern for users who would like to leave
>interactive on in rc (eg they like to use the standard python shell or
>some other shell) and still be able to get the efficiency when running
>scripts from the command shell, it might be possible to inspect
>whether we are in a running in a python shell, and plug this
>additional information into draw_if_interactive.  Something like
>
>def draw_if_interactive():
>     if running_in_python_shell() and matplotlib.is_interactive():
>        canvas.draw()
>
>Anyone know how to determine whether you are running code in a python
>shell versus running a script, eg from a command shell?
>
>It occurs to me that "interactive" is not really the best name for
>this matplotlib state.  Really we want something that conveys
>"draw_after_every_plot_command".  When I named it, I was assuming that
>when working interactively you would want to update with every plot
>command, but have learned that this is not always the case.  Do you
>think it's worth coming up with new names (isdraw(),
>draw_always(True/False), etc, while preserving the old names for a
>while with deprecation)?  Because that's what we're really doing,
>controlling the drawing.
>
>JDH
>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Ted Drain     Jet Propulsion Laboratory   ted...@jp...