In thinking about the ioff(), ion() approach it occurs to
> me that it may not be quite so simple for scripts. I think
> a common desire is for a script or function to turn off
> interactive mode if it is on, but at the end, restore the
> previous interactive state. In this case a push/pop
> approach to interactive mode may be more appropriate rather
> than stop/start. In particular, if interactive mode
> happended to be off, you wouldn't want to turn it on at the
> 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