[SciPy-dev] gui_thread issue
Fernando.Perez at colorado.edu
Sun Nov 7 14:04:59 CST 2004
eric jones wrote:
> Yes, to be clear, gui_thread.start() works fine in my resource files as
> well. The problem comes up when you want to import gui_thread as well
> as a wxPython module (like enthought.chaco.wxplt) as well from within
> the resource file. So, putting something like:
> import_mod gui_thread
> execute gui_thread.start()
> import_some enthought.chaco wxplt
Ah, got it. Unfortunately, there you'll be bitten by the moronic system I
designed for ipython's rc files, which orders the execution of various parts
differently from how you type them in. All module imports are done first, so
the above approach will invariably fail.
Until I rewrite ipython's internals to use real python files for
configuration, this problem will remain. However, there is a simple (if a bit
ugly) workaround: don't use the various import* options I came up with, and
simply put in 'execute' statements directly. Those get applied in the order
you type them, and any python code is valid. So the following should address
execute import gui_thread
execute from enthought.chaco import wxplt
This will ensure that the start() call is made _before_ the wxplt import. The
ipythonrc model is so bad, that these days I typically only put config options
in my rc files, and leave any code I want executed in a real python file.
Then I put at the end of my ipythonrc file:
where foo.py contains all the code I actually want.
All this nonesense will eventually go away, once I can rip out the existing
config system and replace it with a pure python based one. In the meantime,
the execute/execfile workarounds at least provide a solution.
I hope this helps,
More information about the Scipy-dev