[SciPy-dev] gui_thread issue

[eric jones]

Fernando Perez wrote:

> 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.

The code above works perfectly.  Thanks for the explanation.  
Ironically, all the "nonsense" actually makes it work in this case 
because you aren't trying to execute the imports within another module 
import (this is where the single module lock caused problems).  So *not* 
using the pure python approach (at least the standard one of pure 
import) is what makes it work. 

Anyway, thanks for the help.  It looks like Chaco and gui_thread are 
going to play nicely with ipython.  I do have problems with ipython 
exiting correctly.  "Exit" hangs.  Hitting Ctrl-C after that though, 
exits correctly.

One more thing.  Now that I have the necessary "readline" module in my 
site-packages to make ipython colorize correctly, Ctrl-Z no longer works 
to exit a standard python shell or ipython.  Has anyone else had similar 
problems?  Ctrl-C sometimes exits ipython, sometimes not.  I use "import 
sys;sys.exit()" to exit standard python prompts.

thanks,
eric

>
> I hope this helps,
>
> f
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev