[SciPy-dev] gui_thread issue

[Fernando Perez]

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 
your problem:

execute import gui_thread
execute gui_thread.start()
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:

execfile foo.py

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,

f