[SciPy-dev] Generic gui_thread + IPython: solution already exists!
prabhu_r at users.sf.net
Sun Nov 14 20:39:44 CST 2004
>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
>> I actually thought of using this approach earlier when I was
>> fixing gui_thread, but thought IPython would need too many
>> modifications for this to work. However, it looks like
>> Fernando has already done all the work for us.
FP> Well, I think the real credit should go to John Hunter and
FP> Antoon Pardon, the people who cracked the nut of the threading
FP> code originally :)
Well, with all due respect to John, from Shell.py:
by Brian McErlean and John Finlay.
Modified with corrections by Antoon Pardon.
So I think these guys should get the credit for the original idea.
The good thing with IPython is that you control the prompt. So, this
approach is workable for you. It won't work on vanilla Python or
IDLE. That is more than good enough for me. :)
FP> This is great news, obviously!
FP> This is very much what Eric and I originally discussed at
FP> scipy'04, and what I thought might be possible to do. While
Though I was right in the middle of that conversation, I did not
realize that you had taken the approach of pygtkconsole.py. If only I
had known that, I would not have spent the time hacking gui_thread
recently. Well, maybe that is a good thing because we have a
partially working gui_thread if someone needs it.
FP> fumbling in the dark with my near-zero knowledge of threading,
FP> in an attempt to get matplolib running, I finally thought that
FP> perhaps this approach was just not viable, and that the full
FP> complexity of gui_thread was indeed inevitable. I basically
FP> was not willing to believe that such a simple approach could
FP> indeed substitute all the functionality of gui_thread, and
FP> gave up in my ignorance. I'm happy to see that my original
FP> hunch was indeed right :)
FP> The leftover machinery for -wthread/-gthread which you see
FP> there is all that's left of my efforts. I'm glad I didn't
FP> completely wipe that out. Re-enabling it is trivial, and I
FP> even had written the relevant manual parts for it, so this
FP> would be an easy fix.
FP> I would be more than happy to put out a 0.6.5 release with
FP> these fixes, since I think they would be a _major_ enhancement
FP> to ipython.
FP> People have been asking for a long time for a way to use
FP> wx/gtk interactively, and if this solution truly can
FP> substitute gui_thread, I think it's a major win. gui_thread
FP> is complex and brittle, and the work of maintaing it is a
FP> solid time sink with a developer bottleneck: basically only
FP> you and Pearu (I think) understand that code enough to dare
FP> stick your fingers in it. IMO it would be great if we could
FP> just get rid of it without loss of functionality.
No need to get rid of it. The code can be used if someone needs it
but the recommended approach will be to use IPython.
FP> I don't have the necessary expertise to properly test this out
FP> for both wx/gtk, but I'd love to see these improvements go in,
FP> so I hope you or someone else can finish them up.
I can send you a patch for the wxPython stuff and the preliminary work
for gtk. I think John will have to fix the pyGTK code a little more
since he obviously knows a lot more than me about pyGTK.
FP> Great work!
No, once again, I see that I'm just a blithering idiot. I should have
seen this a long while ago. My ignorance has gotten the better of me
again. Better late than never though. ;-)
More information about the Scipy-dev