From: John H. <jdh...@ac...> - 2004-12-12 13:57:04
|
>>>>> "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 |