[SciPy-dev] gui_thread issue

Pearu Peterson pearu at scipy.org
Fri Nov 5 12:48:09 CST 2004

On Fri, 5 Nov 2004, Fernando Perez wrote:

> Prabhu Ramachandran schrieb:
>>>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:
>>     PP> Btw, is there any reason that gui_thread.start() should not be
>>     PP> executed while importing gui_thread? People tend to forget
>>     PP> executing gui_thread.start().
>> The trouble is if you want to access gui_thread functionality without
>> starting the secondary thread.  If I am not mistaken, if
>> gui_thread.start() was called on import and wx was already imported,
>> the import would fail and you can't import anything inside gui_thread.

Hmm, gui_thread.start() could check whether wx has been imported or not.
But what usage cases we need to cover?  gui_thread.start() is useful
only when executing it from interactive python prompt, right?

> Would it not then make sense to reorganize the code a bit?  What about 
> something like:
> # start the secondary thread automatically, ready to use:
> from gui_thread import secondary_thread  # or whatever good name you want
> # pull in subfunctionality _without_ the actual secondary thread starting at 
> all:
> from gui_thread import foo bar examples
> Something like this would be explicit enough ('explicit is better than 
> implicit'), while avoiding the (IMHO error-prone) problem of requiring a 
> standalone gui_thread.start().
> For interactive examples, people would just need to remember to use the first 
> line above.  Minimally longer than 'import gui_thread', but  at least still a 
> single line (and something which can easily fit into an ipython profile :)

Interesting idea. Here's another possibility to execute `import 

   import gui_thread.start


More information about the Scipy-dev mailing list