[SciPy-dev] gui_thread issue
Pearu Peterson
pearu at scipy.org
Fri Nov 5 13:48:09 EST 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
gui_thread;gui_thread.start()`:
import gui_thread.start
Pearu
More information about the SciPy-Dev
mailing list